Re: GtkCanvas requirements?

[Sven Herzberg]

Carlos Garnacho wrote:
> Hello!,
>
> On Fri, 2007-04-20 at 17:11 +0200, Sven Herzberg wrote:
>   
>> Marco Pesenti Gritti wrote:
>> 
>>> There is something which bothers me though. Support for some units,
>>> points for example, would require floating points measures. And I
>>> suspect we don't want to do layout in floating point (instability
>>> issues). Mozilla converts css units in twips (an arbitrary integer
>>> unit, 1/20 of a point). That's a way to go about it I guess, though it
>>> requires conversions it in the canvas items. Better ideas?
>>>   
>> This is a very important aspect, right. Especially with the upcoming
>> *resolution independence* in MacOS X, people will start requesting this
>> feature in GTK+ as well. So we should really add resolution independence
>> to the feature list. This would at least satisfy the request for
>> increasing widget spacing if the resolution increases (so we can have
>> something like "1mm" between widgets).
>> 
>
> Sadly, I see a some problems here:
>
> 1) We don't control the hardware our software is running on.
>   

So, where's this a problem?

> 2) Broken X servers reporting bad dpi values, relying just on
> modern/non-broken servers doesn't look very attractive either...
>   

There are also broken flatpanels that report broken sizes. But this is
not a big deal if the user has got an easy way of specifying the correct
resolution.

> 3) I bet there's still lots of people with 800x600 (or worse) screens
>   

So what? The resolution independence will improve the situation for
them, because 1mm will be less pixels on the same display with 800x600
(compared to 1024x768).

Regards,
  Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Tristan Van Berkom]

On Tue, 2007-04-24 at 08:12 +, Benjamin Otte wrote:
[...]
> So what does that mean for a GtkCanvas?
> 
> The canvas should make it easy to load the full graphical description from a
> file created by a graphic artist. 
[...]

I strongly agree and strongly disagree (which might or might not mean
that we are in agreement ;-D )

IMO GtkCanvas should be very very low level and simple, have support
for canvas items etc to be implemented at will in any programatical
ways thinkable, GtkFlashCanvas on the other hand can feel free to
implement vectorial animated objects as canvas items (or however
the implementation would be, up to the GtkFlashCanvas maintainer)
and load them from an swf stream...

I think it is definitly important to keep in mind the possibility
of a canvas being used to render html, flash or other graphic artist
based material, but we should also be carefull and take baby steps:
we should take this oportunity to focus on how powerfull and fine-tuned
we can make the essential base canvas tools/objects and make that
available as soon as possible, doubtlessly GtkHtmlCanvases and
GtkFlashCanvases will organically evolve from that point and eventually
one of those could be included in gtk+ as well... I think that 
discussion is for another day.

I also have to support Carlos where he says:

But, even being the canvas a great excuse to begin this effort, I don't
think it's going to offer enough improvements to the canvas itself to
deserve such a long wait, I think leaving potential API users with the
current canvas buffet for (say) these two years would harm us in the
medium/long term.


Cheers,
  -Tristan


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Benjamin Otte]

Federico Mena Quintero  ximian.com> writes:

> Now for the other use-case... in GNOME we don't have much experience
> with loading SVG-like things and then manipulating them (think Flash).
> Maybe we can find someone with Flash experience to comment on what API
> would be helpful to them?
> 
Model-View-Controller

Flash is all about being able to separate creating the visual contents from
writing the code to interact with them.
And separating means being able to do both in completely different apps by
completely different people.

I'll give a little intro to this part of Flash now, since I think it is pure 
genius.

Flash knows exactly one graphical object: a shape. You can think of it as a
simple static SVG (no scripting) or better as a cairo_path_t with a
cairo_pattern_t to fill it. That's it. All drawing is done that way.

The most important container object is the Sprite. It's just a timeline that
starts playing automatically. Inside that timeline are placement instructions
(including animnations) how other objects are placed inside it.
Example: draw a ball (the Shape), create a sprite and move the shape up and 
down in its timeline. Tell the timeline to loop and you have a bouncing ball.
This is probably equivalent to a pretty advanced SVG, with animations etc.

Another container object is a Button. A button has 3 states (roughly the Gtk
button states normal, prelight and active) and you place objects for those
states. So you can now put the bouncing ball into the button and only in the
prelight state and boom, you have a nice animated indicator that your mouse is
hovering over a button.

Up to this point, we haven't left the Flash equivalent of Inkscape, we're still
in the realm of the graphic artist. We haven't written a single line of code.
But we have a ball bouncing in front of a button.

To get a feel of how that looks, I recently linked to a tutorial [1] in my blog
[2] that I think describes it quite well.

As Havoc said in the other mail, a programmer interacts with these items using 
a pretty simple API [3].


So what does that mean for a GtkCanvas?

The canvas should make it easy to load the full graphical description from a
file created by a graphic artist. So you want a function like
gtk_canvas_new_from_svg (char *filename). That would create the right amount of
canvas items for the SVG and place them correctly. It would also give you 
access to the items by name like glade: gtk_canvas_get_item_by_name (canvas,
"name"). You probably want an easy way to duplicate them, too.
That way the developers could specify what items they need ("asteroid",
"space-ship", "rocket" and "ufo") and then code the functionality for these
objects into their app and the graphic designers work on the agreed on SVG 
file. And then you end up with a very famous game with even greater graphics. 
[4]

Cheers,
Benjamin


[1] http://www.kirupa.com/developer/flash8/simple_animation.htm
[2] http://www.advogato.org/person/company/diary.html?start=39
[3] http://www.brajeshwar.com/reference/as2/MovieClip.html - note that children
movie clips get their own variable, so if movie has a child named "foo" you can
reference it as movie.foo in your script.
[4] http://en.wikipedia.org/wiki/Image:Asteroi1.png

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Emmanuele Bassi]

On Tue, 2007-04-24 at 00:19 +0100, Damon Chaplin wrote:
>  
> > thinking 'in these days of 64-bit machines' would basically screw up all
> > of the people working on getting GTK+ to work on small devices which -
> > surprise! - have no FPU, hence perform like shit with doubles and
> > floats. in Clutter, for instance, most of the operations are done using
> > fixed point algebra and transforming doubles in the public API into
> > 16.16 or 21.11 fixed point numbers internally; we also expose a fixed
> > point API to avoid using doubles altogether. is this hard? yes. is it
> > necessary? yes. should it be a part of the initial design and
> > implementation? hell, yes. because history teach us that starting with
> > "well, we have 64-bit machines nowadays, what's a double going to do" is
> > the perfect way to hit the wall of performance regressions.
> > 
> > cairo and pango developers and contributors went all the lengths to
> > reduce the floating point usage in their libraries; we shouldn't screw
> > the developers on embedded devices *again*.
> 
> But the cairo API already uses doubles, for coordinates and
> transformations.

I'm not saying that cairo API exposes fixed point values; neither I'm
saying that a GtkCanvas should expose a fixed point API (albeit we went
down this road in Clutter and we will see where that leads). all I'm
saying is that people should not think that the canvas should be design
or targeted for desktop boxes; instead, we avoid screwing up people in
the embedded world. we've been there, we've seen what happens. that's
the only point I was trying to make. really. :-)

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,  E: [EMAIL PROTECTED]
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Benjamin Otte]

Carl Worth  cworth.org> writes:

> I'm quite convinced that using floating-point at the interface, and
> fixed-point internally as needed provides the right combination of
> performance and ease-of-use for cairo. I'd highly recommend any new
> canvas interfaces being proposed follow the same approach.
> 
A huge advantage that a cairo-like API has over a canvas is that it has far less
interaction using the interfaces. In cairo the interfacing goes like this:
-> create surface
-> draw
In a canvas it goes like this:
-> add item
<- query size
-> answer size request
<- allocate size
<- send event
-> answer event
...
So there's a lot more situations where you have to pass doubles.

That being said, I'll trust doubles being slow when I see the numbers. There
have been a lot of complaints about cairo's usage of doubles when it wasn't even
an issue. [1]

But the most important issue for a canvas is its API. If I have to know all
sorts of internal things (like what sort of fixed point magic to apply) to get a
canvas item coded, I'm not gonna code a canvas item. And without canvas items a
canvas is pretty boring. Noone cares about text entries and rectangles.

Benjamin


[1] http://blogs.gnome.org/view/xan/2006/11/06/0 - compare the green and the
blue bar

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Carlos Garnacho]

Hi!,

On Mon, 2007-04-23 at 14:03 -0400, Havoc Pennington wrote: 
> I certainly have not sat down and exhaustively tried to figure this out.

Oh, nice list below, I was somehow thinking a shorter in scope, less
tangential, set of changes.

> 
> There is a fair bit of cruft in the core; if you were starting over, I'm 
> sure you'd want to just kill GdkWindow for example, and many other "Xlib 
> leakages" such as how some of the events work.  You'd want to be 
> Cairo-only, use interfaces instead of objects for the core APIs (widget, 
> container), rethink GtkContainer and its common subclasses (as 
> HippoCanvas does), fix the theme system, blah blah. The list could get 
> pretty long.
> 
> The question is which of these are cosmetic cleanups that aren't really 
> worth it and which add new capabilities, and how long is the new 
> capabilities list. Probably not nearly as long as the cosmetic list.
> 
> Replacing the core with a more canvas-ish solution would not have to be 
> done all in one shot, though; the WidgetCanvasItem and CanvasWidget 
> provide a lot of interoperability. You could also have some of the 
> existing widgets implement the CanvasItem interface directly, for 
> example GtkEntry could be both a GtkWidget and a CanvasItem.
> 
> There's no real disruption to the current core while building a new 
> canvas-style core either, in fact I'd suggest evolving the canvas stuff 
> outside of GTK+ for at least a couple of years. It is probably also true 
> that certain "heavy" widgets such as TextView and TreeView never benefit 
> from conversion to a canvas-like model.

I agree this is a great idea for a testbed independent to GTK+, but even
in this case you could only test a subset of the things mentioned here,
other ones could prove to be hardly interoperable with the current
GtkWidget/GdkEvent functional details (Events handling, GdkWindow
revamp, ...).

IMVHO, such testbed should become directly a gdk/gtkwidget proof of
concept experiment, with two or three widget implementations to play
with, and such codebase could be reused later when it proves to be a
substantial improvement.

But, even being the canvas a great excuse to begin this effort, I don't
think it's going to offer enough improvements to the canvas itself to
deserve such a long wait, I think leaving potential API users with the
current canvas buffet for (say) these two years would harm us in the
medium/long term.

Regards,
   Carlos


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Carl Worth]

On Tue, 24 Apr 2007 00:19:08 +0100, Damon Chaplin wrote:
> On Mon, 2007-04-23 at 20:09 +0100, Emmanuele Bassi wrote:
> > floats. in Clutter, for instance, most of the operations are done using
> > fixed point algebra and transforming doubles in the public API into
> > 16.16 or 21.11 fixed point numbers internally;

That's a similar approach as has been used in cairo very successfully.

> >we also expose a fixed
> > point API to avoid using doubles altogether. is this hard? yes.

As a datapoint, cairo does not do this.

> > cairo and pango developers and contributors went all the lengths to
> > reduce the floating point usage in their libraries; we shouldn't screw
> > the developers on embedded devices *again*.
>
> But the cairo API already uses doubles, for coordinates and
> transformations. So if the canvas used fixed point numbers you'd be
> converting to doubles and then back again.

Some people have misunderstood what kinds of optimizations happened in
cairo.

Cairo has always had a floating-point API, with an implementation that
tries to get to fixed-point as quickly as possible. There were several
performance problems that were fixed between the 1.2 and 1.4 releases
of cairo that involved the following:

* Using clever techniques to make the conversion of floating-point to
  fixed-point values as fast as possible.

* Using similar techniques to make the rounding of floating-point
  values to integers as fast as possible.

* Avoiding floating-point arithmetic where the result was unchanged,
  (multiplying by an identity matrix, for example).

At this point, cairo seems plenty fast on embedded systems for the
kinds of things that people are throwing at it. Now, some of that
speed comes from simply not doing some of the scaling and
transformation that might be desired, (see the identity
transformation optimization mentioned above).

But even if more scaling and rotation were desired, there would be
plenty of ways to optimize this, (using fixed-point arithmetic when
the scaling is small enough to avoid overflow, using fast integer
techniques for computing things like square roots, etc.). And all of
that could be done without ever adding any fixed-point API to cairo.

I'm quite convinced that using floating-point at the interface, and
fixed-point internally as needed provides the right combination of
performance and ease-of-use for cairo. I'd highly recommend any new
canvas interfaces being proposed follow the same approach.

-Carl


pgpzlnZ1k131g.pgp
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Behdad Esfahbod]

On Mon, 2007-04-23 at 19:19 -0400, Damon Chaplin wrote:
> 
> But the cairo API already uses doubles, for coordinates and
> transformations. So if the canvas used fixed point numbers you'd be
> converting to doubles and then back again. With 32-bit fixed point
> numbers you also cut down the maximum possible size of the canvas,
> plus
> you lose the precision of doubles (which may be important for some
> data
> visualization apps). 

I completely agree here with Damon.  With fixed point api, bug reports
will come in very soon that "if I zoom in 1000x on a point and try to
move it, it jumps around...".  We've had similar reports when people
tried to port Inkscape to cairo, because cairo uses a 16.16 fixed point
internally.  When you are locked with fixed point, it would be really
hard to get out of it.  On the other hand, since cairo has double api
already and we don't see adding fixedpoint api any time soon, the canvas
can do a good job at avoiding floating-point arithmetic completely and
use cairo transformations for all the work.  And we have been optimizing
cairo as much as possible to make this usecase fast for example for
non-scale non-rotation matrices.  Doing affine transformations
completely in fixedpoint is very hard, and probably even impossible to
support extreme zoom factors with.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Damon Chaplin]

On Mon, 2007-04-23 at 09:20 -0400, Owen Taylor wrote:

> I want to point out here that while you can specify units in points or
> ems, or whatever, with a data type of fixed point numbers, 
> or doubles, or whatever, you simply can't ignore the pixel grid and
> expect to get good looking results; it matters whether a line is 1.5
> pixels wide (a black line next to a gray line), or 2 pixels wide (a
> black line.)
> 
> It was a deliberate design decision for the HippoCanvas that layout
> happens in integer pixels; a get_width_request() call returns 29px or
> 30px, never 29.5px.
> 
> If you say that a box has a spacing of "10pt" you don't want to
> interpret that as 10 * (96 / 72.) = 13.33 pixels, you want to interpret
> that as 13 pixels.

Yes, I had thought of adding something like an "integer-layout" property
to GooCanvas, so that the layout in containers like GooCanvasTable can
be done in pixels if necessary. I don't think it is that difficult to
add.

Damon


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Damon Chaplin]

On Mon, 2007-04-23 at 20:09 +0100, Emmanuele Bassi wrote:
> On Sun, 2007-04-22 at 21:16 +0100, Damon Chaplin wrote:
> 
> > In these days of 64-bit machines I don't think sizeof (double) is a big
> > deal, if its just for a few coordinates per item. Anyway if we're using
> > interfaces for items then the items can use whatever they like
> > internally.
> 
> it's not a matter of space.
> 
> thinking 'in these days of 64-bit machines' would basically screw up all
> of the people working on getting GTK+ to work on small devices which -
> surprise! - have no FPU, hence perform like shit with doubles and
> floats. in Clutter, for instance, most of the operations are done using
> fixed point algebra and transforming doubles in the public API into
> 16.16 or 21.11 fixed point numbers internally; we also expose a fixed
> point API to avoid using doubles altogether. is this hard? yes. is it
> necessary? yes. should it be a part of the initial design and
> implementation? hell, yes. because history teach us that starting with
> "well, we have 64-bit machines nowadays, what's a double going to do" is
> the perfect way to hit the wall of performance regressions.
> 
> cairo and pango developers and contributors went all the lengths to
> reduce the floating point usage in their libraries; we shouldn't screw
> the developers on embedded devices *again*.

But the cairo API already uses doubles, for coordinates and
transformations. So if the canvas used fixed point numbers you'd be
converting to doubles and then back again. With 32-bit fixed point
numbers you also cut down the maximum possible size of the canvas, plus
you lose the precision of doubles (which may be important for some data
visualization apps).

If the canvas item API uses doubles, items can still use fixed point
numbers internally if necessary.

Damon


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Federico Mena Quintero]

El lun, 23-04-2007 a las 13:44 -0400, Havoc Pennington escribió:

> For most Flash usage, API really is not the issue... people do it like 
> HTML, where they write the markup then add a little bit of scripting 
> (for Flash, it isn't literally markup, but what I mean is 'data not 
> code'). Unlike HTML, the data part is edited in a dedicated app rather 
> than written by hand or using templates.

And a "dedicated app" to create the drawing content is exactly the
killer feature of Flash.  That's what I want to do with "use Inkscape
and slap the SVG into the canvas; then write some simple code to
interact with it".

People in the Real World need a very simple way to do interactive
displays (be it with graphics or just text widgets).  A few years ago in
Brazil I had a gentleman ask me, "why is GTK+ and Glade so complicated?
I'm using a database that lets me write GUIs by typing

   Enter Name []

(write-your-GUI-though-ASCII-art), and it will then let me name the
field, define its type, etc.".

People *need* that level of simplicity.  Draw something, BANG - it's
there.  You just write some glue code to the rest of your app.

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Federico Mena Quintero]

El lun, 23-04-2007 a las 18:50 +0200, Carlos Garnacho escribió:

> On Sat, 2007-04-21 at 10:30 -0500, Federico Mena Quintero wrote:
> >   canvas = new Canvas ();
> >   svg = canvas.load_svg ("foo.svg");
> >   handle = svg.get_object_by_id ("bouncing-ball");
> >   handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4));
> 
> I see this more as a higher level abstraction over the canvas rather
> than an intrinsic feature.

Oh, yeah, definitely.  I just want to avoid architecture-astronauting;
it's pretty easy to do with a canvas.  [In the Piccolo site, look for a
paper about a comparison between a "scene graph canvas" and Piccolo's
current architecture.  They wrote two canvases, one very layered and
abstract which was impossible to use, and a more direct one which was
okay --- they found about this by porting the same software to both
canvases.  Talk about academia having nothing better to do than...] :)

> > The canvas also needs to have performance goals defined up front.  We
> > don't want the case where people avoid using the canvas because it is
> > too slow (like what happened with the antialiased GnomeCanvas).
> 
> hmm, right, what should be a reasonable/feasible goal? visualizing a
> bunch of thousand items with little/no noticeable delay? moving a few
> tenths/hundreds around? I guess that making performance studies on the
> current canvases could help here.

It's very hard to predict what people will put inside a canvas.  I like
the idea that someone posted on cairo-list; unfortunately I don't
remember whom:  it's basically to compare the performance of
swfdec/cairo versus the proprietary Flash player.  We could compare the
performance of our canvas with an equivalent Flash drawing.

[Obligatory mention of http://www.clayloomis.com/Tetka.html - sorry for
the imagery.]

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Emmanuele Bassi]

On Sun, 2007-04-22 at 21:16 +0100, Damon Chaplin wrote:

> In these days of 64-bit machines I don't think sizeof (double) is a big
> deal, if its just for a few coordinates per item. Anyway if we're using
> interfaces for items then the items can use whatever they like
> internally.

it's not a matter of space.

thinking 'in these days of 64-bit machines' would basically screw up all
of the people working on getting GTK+ to work on small devices which -
surprise! - have no FPU, hence perform like shit with doubles and
floats. in Clutter, for instance, most of the operations are done using
fixed point algebra and transforming doubles in the public API into
16.16 or 21.11 fixed point numbers internally; we also expose a fixed
point API to avoid using doubles altogether. is this hard? yes. is it
necessary? yes. should it be a part of the initial design and
implementation? hell, yes. because history teach us that starting with
"well, we have 64-bit machines nowadays, what's a double going to do" is
the perfect way to hit the wall of performance regressions.

cairo and pango developers and contributors went all the lengths to
reduce the floating point usage in their libraries; we shouldn't screw
the developers on embedded devices *again*.

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,  E: [EMAIL PROTECTED]
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Havoc Pennington]

Hi,

Carlos Garnacho wrote:
> What are we missing in the current core? What benefits would bring a new
> one?

I certainly have not sat down and exhaustively tried to figure this out.

There is a fair bit of cruft in the core; if you were starting over, I'm 
sure you'd want to just kill GdkWindow for example, and many other "Xlib 
leakages" such as how some of the events work.  You'd want to be 
Cairo-only, use interfaces instead of objects for the core APIs (widget, 
container), rethink GtkContainer and its common subclasses (as 
HippoCanvas does), fix the theme system, blah blah. The list could get 
pretty long.

The question is which of these are cosmetic cleanups that aren't really 
worth it and which add new capabilities, and how long is the new 
capabilities list. Probably not nearly as long as the cosmetic list.

Replacing the core with a more canvas-ish solution would not have to be 
done all in one shot, though; the WidgetCanvasItem and CanvasWidget 
provide a lot of interoperability. You could also have some of the 
existing widgets implement the CanvasItem interface directly, for 
example GtkEntry could be both a GtkWidget and a CanvasItem.

There's no real disruption to the current core while building a new 
canvas-style core either, in fact I'd suggest evolving the canvas stuff 
outside of GTK+ for at least a couple of years. It is probably also true 
that certain "heavy" widgets such as TextView and TreeView never benefit 
from conversion to a canvas-like model.

New capabilities I can quickly think of, all of which might be possible 
to retrofit into GtkWidget/GtkContainer themselves:
  - better layout
  - overlapping/alpha-blending
  - reduced overhead / more lightweight objects (speculative)
  - better containers replacing [HV]Box/Misc (see HippoCanvasBox and
xalign, yalign, padding, border properties)
  - printing trees of items
  - general ability to draw an item to stuff other than the screen
  - support for nonrectangular items (e.g. a diagonal line)
  - nicer event system (e.g. easier enter/leave tracking, remove
only-useful-for-toplevels stuff from main item interface)

In the end I'm guessing this is just too much work. At the same time, 
for some apps already we see that even a simple answer like HippoCanvas 
has important advantages over GtkWidget.

Havoc

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Havoc Pennington]

Hi,

Federico Mena Quintero wrote:
> Now for the other use-case... in GNOME we don't have much experience
> with loading SVG-like things and then manipulating them (think Flash).
> Maybe we can find someone with Flash experience to comment on what API
> would be helpful to them?

For most Flash usage, API really is not the issue... people do it like 
HTML, where they write the markup then add a little bit of scripting 
(for Flash, it isn't literally markup, but what I mean is 'data not 
code'). Unlike HTML, the data part is edited in a dedicated app rather 
than written by hand or using templates.

When I used Flash, I created a blank rectangle in the editor app, then 
did everything programmatically from ActionScript - but this is 
_clearly_ the thing that 0.01% of programmer freaks do, not something 
that would be common among people who use Flash. No Flash books or docs 
would suggest doing it this way.

One of the big reasons Flash is popular is that graphic designers can 
use it without knowing how to program.

The Flash API looks similar to GnomeCanvas or the DOM in that it's a 
tree of display objects. It's much simpler than either one of those 
though, there's no layout, there are only a few kinds of item, etc.

Havoc

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

RE: GtkCanvas requirements?

[David Moffatt]

>
>e.g. the SVG spec says high quality viewers should use doubles for
>calculations:
>  http://www.w3.org/TR/SVG11/types.html#BasicDataTypes

The problem with double is not the size it is the speed of them.  Right
now there are people like (me) who are trying to use GTK on cell phones.
Working with doubles without hardware support means software emulation
and that is SLOW to the point of unusable.

I wonder if there is a way of using a 64 bit int to get the fidelity of
a double without the overhead.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Carlos Garnacho]

Hello!,

On Fri, 2007-04-20 at 17:11 +0200, Sven Herzberg wrote:
> Marco Pesenti Gritti wrote:
> > There is something which bothers me though. Support for some units,
> > points for example, would require floating points measures. And I
> > suspect we don't want to do layout in floating point (instability
> > issues). Mozilla converts css units in twips (an arbitrary integer
> > unit, 1/20 of a point). That's a way to go about it I guess, though it
> > requires conversions it in the canvas items. Better ideas?
> 
> This is a very important aspect, right. Especially with the upcoming
> *resolution independence* in MacOS X, people will start requesting this
> feature in GTK+ as well. So we should really add resolution independence
> to the feature list. This would at least satisfy the request for
> increasing widget spacing if the resolution increases (so we can have
> something like "1mm" between widgets).

Sadly, I see a some problems here:

1) We don't control the hardware our software is running on.
2) Broken X servers reporting bad dpi values, relying just on
modern/non-broken servers doesn't look very attractive either...
3) I bet there's still lots of people with 800x600 (or worse) screens

Regards,
   Carlos


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Carlos Garnacho]

Hi Federico :),

On Sat, 2007-04-21 at 10:30 -0500, Federico Mena Quintero wrote:
> El jue, 19-04-2007 a las 15:00 -0400, Havoc Pennington escribió:
> 
> > I'd step back first and do use-cases instead, and also talk about at a 
> > high level what the canvas is for and when it would be used, i.e.:
> 
> Havoc is on the right track here.  You can pile an immense feature list
> on top of the canvas and still get a useless thing.  We need use-cases.
> 
> My use-cases for a canvas:
> 
> - Interactive, pre-drawn graphical content which cannot be done with
> stock widgets.  Think of "using Inkscape instead of Glade"; think of a
> poor man's Flash.  People want to do this:
> 
>   canvas = new Canvas ();
>   svg = canvas.load_svg ("foo.svg");
>   handle = svg.get_object_by_id ("bouncing-ball");
>   handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4));

I see this more as a higher level abstraction over the canvas rather
than an intrinsic feature.

> 
> - Interactive diagrams, generated programmatically.  Think of "the sexy
> call-graphs in kcachegrind".  A static diagram is trivial, as you can
> just draw it with Cairo *once* and BitBlt() it when you need it.  An
> interactive diagram is harder, since you need event handling, hit
> testing, painless redraw, etc.
> 
> - Simple games are already covered by the points above.
> 
> - I think we want to focus on simplicity and heavy use of SVG.
> Thousands of programmatically-generated items ("music editor", flyweight
> items, etc.) are not very interesting and could complicate the design a
> lot.

As I see it, with a higher abstraction on the latter you could get the
former.

> 
> - Whoever does a canvas really really really needs to look at
> Piccolo.NET (http://www.cs.umd.edu/hcil/piccolo/).  The animation API is
> lovely, and the support for "zoomable UIs" is lovely as well.  If we had
> Piccolo.NET on top of Cairo and GTK+, we'd have 99% of our needs
> covered.
> 
> [Side note... at this point I think doing a canvas in C is a big
> mistake.  Interesting canvases will inevitably get cycles in the pointer
> graph, and reference counting becomes just too painful then.  [This is
> irrelevant to .net or whatever; it's a general We Should Stop Writing
> Nontrivial Shit In C thing.  People would be really really happy with
> the Piccolo.NET API implemented with pygtk or gtk-sharp.]]

There are already other pieces of complicate software in GTK+ (for
example, GtkTreeView), which have proved to be quite beneficial, and one
of the reasons is that they're implemented in C, and thus, they were
bindable to other languages. IMHO programming a potentially widely used
piece of software in a higher level language would cut down severely its
user base.

> 
> >   - when is a canvas item used vs. a widget? what current widgets would
> > be "replicated" as canvas items?
> 
> If you have a stock canvas item for editable text, you already have 95%
> of the cases covered --- you can compose "editable" mega-items out of
> that text item plus decoration.  That's what we do in the Evolution
> calendar, for instance:  the calendar's appointments are just a bunch of
> boxes and lines plus text items.
> 
> Putting GtkWidgets inside a canvas is a nice gimmick, but I don't think
> you need to make them fully zoomable/transformable/etc.  If you want
> GtkFixed-like layout with canvas drawings underneath, you don't need
> exotic transformations.
> 
> (People often do diagrams which need pushable buttons, and so they want
> to stick a GtkButton inside a canvas.  For that it may be simpler to
> just create a CanvasButton object which you can decorate to your heart's
> content with SVG.)
> 
> The canvas also needs to have performance goals defined up front.  We
> don't want the case where people avoid using the canvas because it is
> too slow (like what happened with the antialiased GnomeCanvas).

hmm, right, what should be a reasonable/feasible goal? visualizing a
bunch of thousand items with little/no noticeable delay? moving a few
tenths/hundreds around? I guess that making performance studies on the
current canvases could help here.

Regards,
   Carlos


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Carlos Garnacho]

Hi Havoc!,

On Fri, 2007-04-20 at 10:13 -0400, Havoc Pennington wrote:
> In HippoCanvas we took this to the extreme of not including gdk.h or 
> gtk.h in the canvas core. I happen to really like this approach, but
> in 
> general I tend to like to keep code almost annoyingly 
> layered/orthogonal, just a personal taste kind of thing that can
> create 
> extra work.
> 
> Then as you mention there's an item that can contain GtkWidget and a 
> GtkWidget that can contain an item.
> 
> It definitely has the downside that you'd have to replicate large parts 
> of what's in gdk and gtk already. On the upside, if you're writing a new 
> "widget core," apps could avoid the old one entirely someday. It's a 
> "GTK 3.0 in parallel and interoperable with 2.x" sort of thing. Probably 
> at least a little bit insane.

What are we missing in the current core? What benefits would bring a new
one? would it be worth in the long term the pain of duplicating code
paths? AFAIK, we're missing advanced layout properties like
height-for-width, width-for-height and such, maybe they would be done
differently if it all were done from scratch, but it seems doable for
2.x.

Regards,
   Carlos


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Federico Mena Quintero]

El dom, 22-04-2007 a las 22:26 +0100, Damon Chaplin escribió:

> So basically it is all kinds of data visualization and manipulation, and
> the occasional animation. Plus some WYSIWYG stuff to be printed.

For the record, I fully trust Damon to do the right thing for the
programmatic side of the canvas.  Many moons ago he had the thankless
job of implementing Evolution's calendar views on top of GnomeCanvas, so
he's quite familiar with the problems which someone using the canvas may
encounter.

Now for the other use-case... in GNOME we don't have much experience
with loading SVG-like things and then manipulating them (think Flash).
Maybe we can find someone with Flash experience to comment on what API
would be helpful to them?

> I spent quite a while reading through the Piccolo docs before writing
> GooCanvas, but I'm afraid I didn't like it that much. The API is
> horribly complicated:

Heh.  But remember that it was developed by academia, after all ;)

Things that I liked from Piccolo:

- The animation scheduler.  You can say "when this bit of the animation
is done, start this other one".

- Being able to animate based on object properties.  "Modify the 'size'
property from 2.5 to 7.0, while you change the 'position' property from
 to , all during 300 milliseconds".

- Having a concept of "scale" for zoomable UIs.

- They actually implemented nontrivial zoomable UIs that work (a
calendar, an image catalog, some PDA stuff).  It would be instructive to
see how these programs use the underlying APIs.

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Tristan Van Berkom]

On Sat, 2007-04-21 at 22:12 +0300, Kalle Vahlman wrote:
> 2007/4/21, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]>:
> >   I can tell you the reasons why I usually use a canvas:
> >
> > 1. Writing widgets is _very hard_ (when compared to e.g. canvas 
> > items).
> 
> Depends on your language (and on your widget of course). In python,
> deriving a widget not a big deal. In C, well I guess you need to grasp
> some concepts but it's hardly rocket sience.
> 

Ahem, 
   yes, writing widgets is very hard - not because of language
orientation but because of the long history of gtk+ - interestingly
I've been away for a week since my internet is down and I see there's
been alot of discussion on the lists... interesting points I've
seen:

Havoc pointed out that - if we were to view the canvas as a completely
alternative widget system core, we would have the oportunity of having
something lightweight (A gtk+ 3.0 without gtk+ 3.0 I think he said); 
this idea is very attractive at first sight... but be warned - in my
limited experience - I've found that (in this corporation where I work),
they went and trashed all the work that we did for 4 years to start a
"new generation" that; in the eyes of the salesmen would solve all of
our problems, in the end it was a huge game of appearences and worked
out well to gain investments for the company etc... but from a developer
point of view it was a big waste of time - we were already on our way
to a huge refactoring phase that would have allowed us to reposition 
ourselves for future needs without trashing everything that was already
written and was already good (this was already going to be a huge cost,
but not nearly as huge as the "new generation" route)... sorry for the
long winded analogy but it just goes to say that a technically complex
problem requires alot of thought and we shouldnt shy away from trying
to understand the code that people have written 5 years ago and improve
upon it/refactor it.

Another (Clemens Eisserer) in a seperate thread[1] pointed out an
interesting way that things could be improved in gtk+, optimizing
backbuffering etc, hell from my point of view; GtkWidgets could 
probably be simplified if the resource management (GdkWindow allocations
etc for every damn widget that must support GTK_NO_WINDOW cases or
not etc etc) were just deffered out of the typical GtkWidget context.

Thats why I'm replying to THIS mail in the thread, GtkWidget's are
complex and difficult to write because of the requirements that they
meet, this doesnt mean we must sadly lose all hope in them and write
something new for the sake of something new just because nobody has
the balls to go and refactor the core, Clemens has balls and for
that I salute him :)

Canvases... thats right this thread is about canvases... canvases
historically have been something great for highly customized application
environments, but there are so very many applications that need widgets,
just basic building blocks, a button here, a slider there, a nicely
resizing container - and there you have a simple GUI tool frontend for
your typical unix CLI program that is essential to your system.

I think its clear we need canvases, and we need all the themable
goodness that works out of the box that is gtk+ as well, personally
I dont think those two things go in the same boat.

A good day to you all,
  -Tristan

[1]http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00074.html


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Owen Taylor]

On Sun, 2007-04-22 at 21:16 +0100, Damon Chaplin wrote:
> On Thu, 2007-04-19 at 16:19 -0400, Havoc Pennington wrote:
> > Marco Pesenti Gritti wrote:
> > > There is something which bothers me though. Support for some units, 
> > > points for example, would require floating points measures. And I 
> > > suspect we don't want to do layout in floating point (instability 
> > > issues). Mozilla converts css units in twips (an arbitrary integer unit, 
> > > 1/20 of a point). That's a way to go about it I guess, though it 
> > > requires conversions it in the canvas items. Better ideas?
> > > 
> > 
> > I agree that it would be really good to avoid floating point. Pixels are 
> > by far the most intuitive thing for people using or writing items, too 
> > (since as you say they avoid having to multiply everything). Pango does 
> > have the precedent though and for convenience we could just use the same 
> > units as Pango.
> 
> I don't really think that pixels or fixed point integers are enough for
> a general purpose canvas. If people want to write complex layout apps
> like DTP/illustration packages they need more precise control over
> coordinates (and in different units like points/millimeters/inches).
> 
> e.g. the SVG spec says high quality viewers should use doubles for
> calculations:
>   http://www.w3.org/TR/SVG11/types.html#BasicDataTypes

I want to point out here that while you can specify units in points or
ems, or whatever, with a data type of fixed point numbers, 
or doubles, or whatever, you simply can't ignore the pixel grid and
expect to get good looking results; it matters whether a line is 1.5
pixels wide (a black line next to a gray line), or 2 pixels wide (a
black line.)

It was a deliberate design decision for the HippoCanvas that layout
happens in integer pixels; a get_width_request() call returns 29px or
30px, never 29.5px.

If you say that a box has a spacing of "10pt" you don't want to
interpret that as 10 * (96 / 72.) = 13.33 pixels, you want to interpret
that as 13 pixels.

Don't forget the pixel!
- Owen

(This is, of course, different for a "widgety" use of a Canvas as
compared to a WYSYWIG use of the canvas. I'm not sure what that implies
for trying to use the same canvas for both. Maybe a global setting
or the right layered design can give sufficient flexibility.)


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Damon Chaplin]

On Sat, 2007-04-21 at 10:30 -0500, Federico Mena Quintero wrote:
> El jue, 19-04-2007 a las 15:00 -0400, Havoc Pennington escribió:
> 
> > I'd step back first and do use-cases instead, and also talk about at a 
> > high level what the canvas is for and when it would be used, i.e.:
> 
> Havoc is on the right track here.  You can pile an immense feature list
> on top of the canvas and still get a useless thing.  We need use-cases.
> 
> My use-cases for a canvas:
> 
> - Interactive, pre-drawn graphical content which cannot be done with
> stock widgets.  Think of "using Inkscape instead of Glade"; think of a
> poor man's Flash.  People want to do this:
> 
>   canvas = new Canvas ();
>   svg = canvas.load_svg ("foo.svg");
>   handle = svg.get_object_by_id ("bouncing-ball");
>   handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4));
> 
> - Interactive diagrams, generated programmatically.  Think of "the sexy
> call-graphs in kcachegrind".  A static diagram is trivial, as you can
> just draw it with Cairo *once* and BitBlt() it when you need it.  An
> interactive diagram is harder, since you need event handling, hit
> testing, painless redraw, etc.
> 
> - Simple games are already covered by the points above.

Here's some use-cases mentioned on the GooCanvas list:

 - DTP app (that's what I originally wrote it for).
 - Multi-track audio editor (currently uses GnomeCanvas).
 - Genome viewer (currently uses FooCanvas).
 - Air traffic controller simulator.
 - Database relationship viewer.
 - PIM Synchronizer connection viewer.

So basically it is all kinds of data visualization and manipulation, and
the occasional animation. Plus some WYSIWYG stuff to be printed.


> - I think we want to focus on simplicity and heavy use of SVG.
> Thousands of programmatically-generated items ("music editor", flyweight
> items, etc.) are not very interesting and could complicate the design a
> lot.
> 
> - Whoever does a canvas really really really needs to look at
> Piccolo.NET (http://www.cs.umd.edu/hcil/piccolo/).  The animation API is
> lovely, and the support for "zoomable UIs" is lovely as well.  If we had
> Piccolo.NET on top of Cairo and GTK+, we'd have 99% of our needs
> covered.

I spent quite a while reading through the Piccolo docs before writing
GooCanvas, but I'm afraid I didn't like it that much. The API is
horribly complicated:
  http://www.cs.umd.edu/hcil/piccolo/learn/piccolo/doc-1.2/api/

What was great about the animation API and zoomable UIs? As far as I
could see zoomable UIs just meant using different painting code at
different scales, which isn't that difficult:
  http://www.cs.umd.edu/hcil/piccolo/learn/patterns.shtml#Desing%
20Patterns%20for%20ZUI%20Interaces

I basically copied what they did for their convenience animation
functions, but it didn't work well for rotations so I had to rewrite it.

I thought SVG was a much nicer model.


> [Side note... at this point I think doing a canvas in C is a big
> mistake.  Interesting canvases will inevitably get cycles in the pointer
> graph, and reference counting becomes just too painful then.  [This is
> irrelevant to .net or whatever; it's a general We Should Stop Writing
> Nontrivial Shit In C thing.  People would be really really happy with
> the Piccolo.NET API implemented with pygtk or gtk-sharp.]]

I don't really agree about the reference counting - noone has reported
problems yet.

I don't think C is that bad. GLib and GTK+ are a bit painful at times,
but hard problems are hard in any language.


> The canvas also needs to have performance goals defined up front.  We
> don't want the case where people avoid using the canvas because it is
> too slow (like what happened with the antialiased GnomeCanvas).

GooCanvas has a demo that creates 100,000 items over a large canvas. The
main problem is startup time of about 5 seconds (creating all the items
and measuring text item widths probably). But it works fine after that.

Damon


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Damon Chaplin]

On Thu, 2007-04-19 at 16:19 -0400, Havoc Pennington wrote:
> Marco Pesenti Gritti wrote:
> > There is something which bothers me though. Support for some units, 
> > points for example, would require floating points measures. And I 
> > suspect we don't want to do layout in floating point (instability 
> > issues). Mozilla converts css units in twips (an arbitrary integer unit, 
> > 1/20 of a point). That's a way to go about it I guess, though it 
> > requires conversions it in the canvas items. Better ideas?
> > 
> 
> I agree that it would be really good to avoid floating point. Pixels are 
> by far the most intuitive thing for people using or writing items, too 
> (since as you say they avoid having to multiply everything). Pango does 
> have the precedent though and for convenience we could just use the same 
> units as Pango.

I don't really think that pixels or fixed point integers are enough for
a general purpose canvas. If people want to write complex layout apps
like DTP/illustration packages they need more precise control over
coordinates (and in different units like points/millimeters/inches).

e.g. the SVG spec says high quality viewers should use doubles for
calculations:
  http://www.w3.org/TR/SVG11/types.html#BasicDataTypes


> Maybe there's some way to make this optional, for example items that 
> feel they can do something useful with sub-pixel sizes could implement 
> an interface that did the size negotiation in sub-pixels. The default 
> implementation of the sub-pixel size negotiation methods would call the 
> whole pixels one, and the default implementation of the whole-pixels 
> methods would call the sub-pixels one and round off. If you didn't 
> override either one it would break badly, but don't do that then ;-)
> all items would have to implement one or the other but not both.
> 
> One downside of doubles is simply the extra memory usage when storing 
> coordinates; I think keeping the abstract base class for items and most 
> common concrete classes as small as possible is a nice win. I'd like to 
> see items be "lighter" than GtkWidget, in almost any of the usage 
> scenarios (widget core or drawing api or other).

In these days of 64-bit machines I don't think sizeof (double) is a big
deal, if its just for a few coordinates per item. Anyway if we're using
interfaces for items then the items can use whatever they like
internally.

Damon


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Gustavo J. A. M. Carneiro]

On Sáb, 2007-04-21 at 17:09 -0400, Havoc Pennington wrote:
[...]
> So another structure could be that there's a "core" which tries to 
> encapsulate the minimum amount of structure for multiple objects to 
> negotiate their usage of the screen area and keyboard, and then there 
> are objects that layer in more widget-like and more svg/flash-like 
> behaviors. Don't know exactly how that would work.

  I agree that a layered solution is the way to go.  The layers I
envision are along these lines:

  1- An immediate mode drawing layer: we have this now, it is called
Cairo;

  2- A retained mode drawing layer: a bunch of "objects" that know how
to paint themselves, and when pointer or keyboard events belong to them.
GooCanvas is one example of such a layer (except that it also does stuff
like animations which I don't think belong in this layer).

  3- Then we can have a bunch of modules on top of layer-2:
3a- animations;
3b- object drag-and-drop;
3c- markup language, scripting, SVG, etc.

> 
> Federico also brings up again the great point that the whole thing 
> should perhaps be designed for primarily markup, plus some scripting, 
> rather than primarily as a programming API.
> 
> Maybe the as-lightweight-as-possible "core" has some ideas like:
>   - the whole display is a DOM-like tree, loadable from markup
>   - item painting
>   - keyboard focus
>   - ...

  Yes, I agree with this view, except that I hope you mean DOM-like tree
is just a programmatic object tree, like gtk widgets, not XML.  I think
glade/libglade/gtk clearly have proved to us that you can perfectly
layer XML on top of a core library.

> 
> Then add a set of "widget" style items built on the core which have:
>   - layout management
>   - themes
>   - keyboard accelerators/mnemonics
>   - ...
> 
> And have a set of "SVG" items (could just be SVG embedded in the overall 
> markup), used for drawing and animations.
> 
> Just brainstorming on how to break down the big picture enough to get a 
> handle on it...

  This is all very nice except that I believe that for now we should
focus on only "layer-2" for inclusion in Gtk+, and only time will tell
how many layer-3+ modules belong in Gtk+, or how much of that is
application-specific.  But even if it belongs in Gtk+, I believe a clear
separation of the layers 2 and 3 is crucial.

-- 
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Petr Tomasek]

On Sat, Apr 21, 2007 at 05:09:09PM -0400, Havoc Pennington wrote:
> Hi,
> 
> Kalle Vahlman wrote:
> >> 6. I want to make slightly interactive diagrams with a clearly
> >> distinctive style from regular gtk widgets, namely i want to draw math
> >> plots for later export into articles.  For this kind of content, users
> >> don't want their selection of gtk theme to interfere with final content,
> >> and the content should have white background and simple colors, none of
> >> these gradients and 3d look that widgets have.
> > 
> > This is what I have thought as the main use of a canvas widget. This
> > thread indicates that people seem to want a lot more than that though.
> > 
> 
> Remember we might need multiple solutions to avoid cramming everything 
> anyone ever wanted to do into one thing.
> 
>   - Document Editor. The "interactive math plot" or "implement inkscape" 
> type of use; "writing a document editor widget"

Well, there definitelly is a need for more layout-capable text-widget,
maybe the GtkTextView and the new canvas could possibly be merged
somehow?

P.T.

-- 
Petr Tomasek 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Havoc Pennington]

Hi,

Kalle Vahlman wrote:
>> 6. I want to make slightly interactive diagrams with a clearly
>> distinctive style from regular gtk widgets, namely i want to draw math
>> plots for later export into articles.  For this kind of content, users
>> don't want their selection of gtk theme to interfere with final content,
>> and the content should have white background and simple colors, none of
>> these gradients and 3d look that widgets have.
> 
> This is what I have thought as the main use of a canvas widget. This
> thread indicates that people seem to want a lot more than that though.
> 

Remember we might need multiple solutions to avoid cramming everything 
anyone ever wanted to do into one thing.

  - Document Editor. The "interactive math plot" or "implement inkscape" 
type of use; "writing a document editor widget"

  - More Flexible Widget Kit. For creating UIs like some of the fancy 
control center shells, Mugshot, something like GMail, etc.

  - Animations and Games. The core use-cases for Flash. Note that this 
may imply that the solution is designed first for *visual designers* and 
only second for programmers (as Flash in fact is - ActionScript APIs, 
argh! - but the Flash designer app is pretty nice)

Perhaps a "nested" solution is the right one - that is, think of how 
HTML has Flash and the new  tag nested inside. Perhaps on the 
outside layer you have a "More Flexible Widget Kit" (or just an 
evolution of GtkWidget), and on the inside layer you have a 
/Piccolo/Flash-type canvas with animations, full affine 
transforms, SVG, and even video.

The problem is that there's a good amount of intersection between the 
two. Maybe in the "Animations and Games" canvas you don't usually want 
layout, but it would still be handy sometimes, for example.

So another structure could be that there's a "core" which tries to 
encapsulate the minimum amount of structure for multiple objects to 
negotiate their usage of the screen area and keyboard, and then there 
are objects that layer in more widget-like and more svg/flash-like 
behaviors. Don't know exactly how that would work.

Federico also brings up again the great point that the whole thing 
should perhaps be designed for primarily markup, plus some scripting, 
rather than primarily as a programming API.

Maybe the as-lightweight-as-possible "core" has some ideas like:
  - the whole display is a DOM-like tree, loadable from markup
  - item painting
  - keyboard focus
  - ...

Then add a set of "widget" style items built on the core which have:
  - layout management
  - themes
  - keyboard accelerators/mnemonics
  - ...

And have a set of "SVG" items (could just be SVG embedded in the overall 
markup), used for drawing and animations.

Just brainstorming on how to break down the big picture enough to get a 
handle on it...

Havoc

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Mathias Hasselmann]

Am Samstag, den 21.04.2007, 11:57 -0500 schrieb Yevgen Muntyan:
> Federico Mena Quintero wrote:
> 
> [snip]
> 
> > [Side note... at this point I think doing a canvas in C is a big
> > mistake.  Interesting canvases will inevitably get cycles in the pointer
> > graph, and reference counting becomes just too painful then.  [This is
> > irrelevant to .net or whatever; it's a general We Should Stop Writing
> > Nontrivial Shit In C thing.  People would be really really happy with
> > the Piccolo.NET API implemented with pygtk or gtk-sharp.]]
> >   
> Only mono (python) people would be happy with whatever implemented
> in gtk-sharp (python). If it's not C, then everybody implements same
> thing in their favorite language. Unfortunately, "it is just hard to
> implement so we use that one" works only if "that one" is written in
> C. Even if you forget about problems of interoperability between
> different languages (some bindings do work two ways, e.g. pygtk;
> some don't, e.g. gtkmm).
> So while it's good to write something totally good in C# (and same thing
> about python, vala, C++, and lisp), it's totally useless as "GTK canvas".

I agree for you, expect for Vala where you are wrong: Vala doesn't
directly produce machine or byte code, it produces standard C code with
standard C headers. So technically writing something in Vala is the same
as writing something in C - expect that you save alot of typing. As the
Vala parser itself is avaiable as GObject library, it even should by
extremly easy to generate GAPI files for language bindings directly
(without parsing the generated C code).

Ciao,
Mathias
-- 
Mathias Hasselmann <[EMAIL PROTECTED]>
http://taschenorakel.de/
-- 
Mathias Hasselmann <[EMAIL PROTECTED]>
http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Kalle Vahlman]

2007/4/21, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]>:
>   I can tell you the reasons why I usually use a canvas:
>
> 1. Writing widgets is _very hard_ (when compared to e.g. canvas 
> items).

Depends on your language (and on your widget of course). In python,
deriving a widget not a big deal. In C, well I guess you need to grasp
some concepts but it's hardly rocket sience.

In general, I think people are easily intimitated by the notion of
creating a new widget.They go "ooh, new widget, HARD!" and then go and
implement pretty much the same functionality by connecting to signals
and overriding them (which IMO results in uglier code, and is harder
to reuse), perhaps using even more effort than what it would take to
c&p some boilerplate code for a widget and doing it "properly". I
guess that's the price to pay for non-oo-native language :/

> 2. Dynamically creating tons of widgets is costly, or at least I get
> that impression, due to round-trips when creating gdk windows, or gdk
> contexts, or whatever;

Most widgets don't have windows, so that shouldn't be a problem.
Per-widget (private) structures might be, but I doubt it would show up
significantly (unless we are literally talking about thousands of
them). The last option you give seems to imply that this is again a
case of "it MUST be costly, right?" rather than "look, it's costly
since !".

> 3. The Gtk widget size negotiation protocol is not flexible enough;

That's true, although good things are under development currently (in SoC).

> 4. Widgets cannot be printed to a PDF file or printer while preserving
> full vectorial information (and no, taking a pixmap of a window and
> printing that is certainly not good enough for quality publishing);

Shouldn't this be almost good with the printing API these days?

> 5. Overlaying widgets and making translucent widgets is difficult or
> impossible;

I hope we can work this one out (since it seems to be quite popular
demand, lord knows why ;), maybe GTK+ should have some support in
widget API for the composite extension / similar implementations for
other platforms?

> 6. I want to make slightly interactive diagrams with a clearly
> distinctive style from regular gtk widgets, namely i want to draw math
> plots for later export into articles.  For this kind of content, users
> don't want their selection of gtk theme to interfere with final content,
> and the content should have white background and simple colors, none of
> these gradients and 3d look that widgets have.

This is what I have thought as the main use of a canvas widget. This
thread indicates that people seem to want a lot more than that though.

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Gustavo J. A. M. Carneiro]

On Qui, 2007-04-19 at 15:00 -0400, Havoc Pennington wrote:
> Hi,
> 
> Carlos Garnacho wrote:
> > First of all we need to specify the feature requirements for the  
> > canvas.
> 
> I'd step back first and do use-cases instead, and also talk about at a 
> high level what the canvas is for and when it would be used, i.e.:
> 
>   - when is a canvas item used vs. a widget? what current widgets would
> be "replicated" as canvas items?
>   - when is a canvas used vs. just drawing to a drawable with Cairo and
> Pango?
>   - is the canvas essentially a fixed-up replacement for
> GtkWidget/GtkContainer (the GTK widget core) or does it have some
> other purpose? If it has another purpose, what is it?
>   - can a list of use cases be spelled out?
>   - how are existing canvases being used? which apps seem to be
> using canvases and why and for what?

  I can tell you the reasons why I usually use a canvas:

1. Writing widgets is _very hard_ (when compared to e.g. canvas items).

2. Dynamically creating tons of widgets is costly, or at least I get
that impression, due to round-trips when creating gdk windows, or gdk
contexts, or whatever;

3. The Gtk widget size negotiation protocol is not flexible enough;

4. Widgets cannot be printed to a PDF file or printer while preserving
full vectorial information (and no, taking a pixmap of a window and
printing that is certainly not good enough for quality publishing);

5. Overlaying widgets and making translucent widgets is difficult or
impossible;

6. I want to make slightly interactive diagrams with a clearly
distinctive style from regular gtk widgets, namely i want to draw math
plots for later export into articles.  For this kind of content, users
don't want their selection of gtk theme to interfere with final content,
and the content should have white background and simple colors, none of
these gradients and 3d look that widgets have.

  These are my reasons.  I will not comment on whether or not the gtk
widget system could fulfill my needs.

-- 
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Yevgen Muntyan]

Federico Mena Quintero wrote:

[snip]

> [Side note... at this point I think doing a canvas in C is a big
> mistake.  Interesting canvases will inevitably get cycles in the pointer
> graph, and reference counting becomes just too painful then.  [This is
> irrelevant to .net or whatever; it's a general We Should Stop Writing
> Nontrivial Shit In C thing.  People would be really really happy with
> the Piccolo.NET API implemented with pygtk or gtk-sharp.]]
>   
Only mono (python) people would be happy with whatever implemented
in gtk-sharp (python). If it's not C, then everybody implements same
thing in their favorite language. Unfortunately, "it is just hard to
implement so we use that one" works only if "that one" is written in
C. Even if you forget about problems of interoperability between
different languages (some bindings do work two ways, e.g. pygtk;
some don't, e.g. gtkmm).
So while it's good to write something totally good in C# (and same thing
about python, vala, C++, and lisp), it's totally useless as "GTK canvas".

Best regards,
Yevgen

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Mathias Hasselmann]

Hmm: Once again I too fast on pressing send and forgot the links:

Vala: http://live.gnome.org/Vala
EggDocument: http://taschenorakel.de/svn/repos/eggdocument/trunk/

Am Samstag, den 21.04.2007, 17:49 +0200 schrieb Mathias Hasselmann:
> Am Samstag, den 21.04.2007, 10:30 -0500 schrieb Federico Mena Quintero:
> > [Side note... at this point I think doing a canvas in C is a big
> > mistake.  Interesting canvases will inevitably get cycles in the pointer
> > graph, and reference counting becomes just too painful then.  [This is
> > irrelevant to .net or whatever; it's a general We Should Stop Writing
> > Nontrivial Shit In C thing.  People would be really really happy with
> > the Piccolo.NET API implemented with pygtk or gtk-sharp.]]
> 
> I'd rather consider using Vala in that case: It gives you a highlevel
> syntax for the GObject system, whilest generating native, binding
> friendly code. GNOME avoids using high-level languages for libraries
> for good reason: Bindings and politics.
> 
> Used it for toying with some document model for printing [1] and expect
> for minor bugs in Vala's code generator, which where resolved quickly,
> vala worked pretty well for me in creating a native GObject library.
> 
> 
> Ciao,
> Mathias
-- 
Mathias Hasselmann <[EMAIL PROTECTED]>
http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Mathias Hasselmann]

Am Samstag, den 21.04.2007, 10:30 -0500 schrieb Federico Mena Quintero:
> [Side note... at this point I think doing a canvas in C is a big
> mistake.  Interesting canvases will inevitably get cycles in the pointer
> graph, and reference counting becomes just too painful then.  [This is
> irrelevant to .net or whatever; it's a general We Should Stop Writing
> Nontrivial Shit In C thing.  People would be really really happy with
> the Piccolo.NET API implemented with pygtk or gtk-sharp.]]

I'd rather consider using Vala in that case: It gives you a highlevel
syntax for the GObject system, whilest generating native, binding
friendly code. GNOME avoids using high-level languages for libraries
for good reason: Bindings and politics.

Used it for toying with some document model for printing [1] and expect
for minor bugs in Vala's code generator, which where resolved quickly,
vala worked pretty well for me in creating a native GObject library.


Ciao,
Mathias
-- 
Mathias Hasselmann <[EMAIL PROTECTED]>
http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Federico Mena Quintero]

El jue, 19-04-2007 a las 15:00 -0400, Havoc Pennington escribió:

> I'd step back first and do use-cases instead, and also talk about at a 
> high level what the canvas is for and when it would be used, i.e.:

Havoc is on the right track here.  You can pile an immense feature list
on top of the canvas and still get a useless thing.  We need use-cases.

My use-cases for a canvas:

- Interactive, pre-drawn graphical content which cannot be done with
stock widgets.  Think of "using Inkscape instead of Glade"; think of a
poor man's Flash.  People want to do this:

  canvas = new Canvas ();
  svg = canvas.load_svg ("foo.svg");
  handle = svg.get_object_by_id ("bouncing-ball");
  handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4));

- Interactive diagrams, generated programmatically.  Think of "the sexy
call-graphs in kcachegrind".  A static diagram is trivial, as you can
just draw it with Cairo *once* and BitBlt() it when you need it.  An
interactive diagram is harder, since you need event handling, hit
testing, painless redraw, etc.

- Simple games are already covered by the points above.

- I think we want to focus on simplicity and heavy use of SVG.
Thousands of programmatically-generated items ("music editor", flyweight
items, etc.) are not very interesting and could complicate the design a
lot.

- Whoever does a canvas really really really needs to look at
Piccolo.NET (http://www.cs.umd.edu/hcil/piccolo/).  The animation API is
lovely, and the support for "zoomable UIs" is lovely as well.  If we had
Piccolo.NET on top of Cairo and GTK+, we'd have 99% of our needs
covered.

[Side note... at this point I think doing a canvas in C is a big
mistake.  Interesting canvases will inevitably get cycles in the pointer
graph, and reference counting becomes just too painful then.  [This is
irrelevant to .net or whatever; it's a general We Should Stop Writing
Nontrivial Shit In C thing.  People would be really really happy with
the Piccolo.NET API implemented with pygtk or gtk-sharp.]]

>   - when is a canvas item used vs. a widget? what current widgets would
> be "replicated" as canvas items?

If you have a stock canvas item for editable text, you already have 95%
of the cases covered --- you can compose "editable" mega-items out of
that text item plus decoration.  That's what we do in the Evolution
calendar, for instance:  the calendar's appointments are just a bunch of
boxes and lines plus text items.

Putting GtkWidgets inside a canvas is a nice gimmick, but I don't think
you need to make them fully zoomable/transformable/etc.  If you want
GtkFixed-like layout with canvas drawings underneath, you don't need
exotic transformations.

(People often do diagrams which need pushable buttons, and so they want
to stick a GtkButton inside a canvas.  For that it may be simpler to
just create a CanvasButton object which you can decorate to your heart's
content with SVG.)

The canvas also needs to have performance goals defined up front.  We
don't want the case where people avoid using the canvas because it is
too slow (like what happened with the antialiased GnomeCanvas).

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Cody Russell]

On Fri, 2007-04-20 at 12:02 +0200, Sven Herzberg wrote:
> 
> Well, isn't the "right" way to go the cairo path and make the
> communication of cairo and the GPU faster (that's "improve Xrender,
> the
> drivers etc.")? As this needs to be improved for a "GPU based GTK"
> anyway you won't get any advantage by adding this new level of
> "platform
> independence" to GTK (which is already available in cairo). 

What I was envisioning is more along the lines of having the widget
system drawn as texture-mapped vertices in the GL, with the textures
being drawn by Cairo and such.  Some textures are repeatable, which
means once it is rendered one time then even upon configure events you
never need to render it again (except maybe for widget state changes).
Also, it could be theoretically possible to implement layout managers as
vertex shader programs.  These are just some ideas.

I'm not sure how this compares to doing the current system + Glitz
surfaces.  When you use Glitz, how is it drawing the surfaces?  If you
have 20 different Glitz surfaces in your window, does each one get
rendered with a separate GL pass?

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Sven Herzberg]

Marco Pesenti Gritti wrote:
> There is something which bothers me though. Support for some units,
> points for example, would require floating points measures. And I
> suspect we don't want to do layout in floating point (instability
> issues). Mozilla converts css units in twips (an arbitrary integer
> unit, 1/20 of a point). That's a way to go about it I guess, though it
> requires conversions it in the canvas items. Better ideas?

This is a very important aspect, right. Especially with the upcoming
*resolution independence* in MacOS X, people will start requesting this
feature in GTK+ as well. So we should really add resolution independence
to the feature list. This would at least satisfy the request for
increasing widget spacing if the resolution increases (so we can have
something like "1mm" between widgets).


Regards,
  Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Dominic Lachowicz]

> So does Gtk want to reduce themeing and just have a simple file that specifies
> colors (like Metacity) or does it want to increase its features to allow stuff
> such as allowing theme engines to do animations, fades and what do I know?

If we care about looking native on Win32 and OSX, I'd say that rules
out the "simple file that specifies colors" approach.

Dom
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Benjamin Otte]

Sven Herzberg  gnome-de.org> writes:

> Sounds pretty good until this point. Benjamin just mentioned in IRC that
> *theming* is also pretty important. We want to be able to render the
> same canvas item in different ways for different themes.
> 
Let me elaborate on this a bit. I think right now everyone would just say "make
sure the gtk_paint_foo functions work on the canvas".

I have no clue where Gtk wants to go with its support for themeing, but the
current approach for themeing is lacking. Not only in that theme engine writers
think it sucks, but in particular if you look at current possibilities and
compare it to the newer display engines like the iPhone [1] or Compiz [2].
OTOH the amount of useful theme engines has been quite limited. I'm not aware of
anything really new since Clearlooks (and even that wasn't radically new).

So does Gtk want to reduce themeing and just have a simple file that specifies
colors (like Metacity) or does it want to increase its features to allow stuff
such as allowing theme engines to do animations, fades and what do I know?

This seems like an important question to me since a canvas looks like the place
where this approach would be tested first.

Cheers,
Benjamin


[1]
http://www.google.com/url?sa=t&ct=res&cd=2&url=http%3A%2F%2Fwww.apple.com%2Fiphone%2Fphone%2F&ei=P8soRtSwJIfgnAP3l7WFAw&usg=AFrqEzeH-MauqKxnTqdDfrV5uDjfBNFh_Q&sig2=HBq0ZWprcLSiamgZotpdzg
[2] Try to imagine Compiz were written using GtkCanvas and every application was
a CanvasItem. How much code would the flames animation take?

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Havoc Pennington]

Sven Herzberg wrote:
> I don't think the GtkWidget API and the GtkCanvas API shouldn't be tied
> together too much.

In HippoCanvas we took this to the extreme of not including gdk.h or 
gtk.h in the canvas core. I happen to really like this approach, but in 
general I tend to like to keep code almost annoyingly 
layered/orthogonal, just a personal taste kind of thing that can create 
extra work.

Then as you mention there's an item that can contain GtkWidget and a 
GtkWidget that can contain an item.

It definitely has the downside that you'd have to replicate large parts 
of what's in gdk and gtk already. On the upside, if you're writing a new 
"widget core," apps could avoid the old one entirely someday. It's a 
"GTK 3.0 in parallel and interoperable with 2.x" sort of thing. Probably 
at least a little bit insane.

Havoc

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Sven Herzberg]

Carlos Garnacho wrote:
> First of all we need to specify the feature requirements for the  
> canvas. The following is a list of features I think we should  
> consider, hope it's a good start, please add to it if there are others:
>
> - GTK+ suitable API.
> - a11y support.
> - Model/View split.
> - Size negociation, height for width, width for height and natural size.
> - object shapes, collision detection.
> - animation framework (perhaps should be more tied to GTK+, GtkTimeLine
> maybe?).
> - get the offscreen rendering patch in.
> - GtkPrint* integration.
> - grouping/ungrouping.
> - extensibility, being able to create new canvas elements with little
> effort.
> - DnD support.
>   

Sounds pretty good until this point. Benjamin just mentioned in IRC that
*theming* is also pretty important. We want to be able to render the
same canvas item in different ways for different themes.

> - Integrate tightly GTK+ and the canvas, even making GtkWidgets
> specialized canvas elements drawn with a certain layout in a canvas, see
> Havoc's proposal [3]
>   

I don't think the GtkWidget API and the GtkCanvas API shouldn't be tied
together too much.  I would like to see the canvas approch being "the
new API" and the widget API to become some legacy API (to make app
porting easier). As long as we can have these two things everything
should be fine:

1. A CanvasWidget: a canvas item that can serve as a GtkContainer for
GtkWidgets (so you can have widgets inside the canvas)
2. A WidgetCanvas: a GtkWidget that displays a GtkCanvas

You can do everything you want with this structure, so I don't think
there's a large need more (but maybe I'm alone with this opinion).

Regards,
  Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Sven Herzberg]

Cody Russell wrote:
> I'd like the canvas system to be generalized enough that we can have
> multiple implementations of it, in the same way that GDK allows us to
> port to Win32 or MacOSX.  In particular, I think we could have an
> implementation that is much like what most of the canvases are doing
> today where everything is software rendered..

Well, there are actually two generations of GTK+ related canvases out
there. The GnomeCanvas family (with FooCanvas), which indeed does all
the rendering in software. And then there's the cairo-based generation
(libccc, goocanvas, hippocanvas, …). The cairo-based generation already
isn't forced to being rendered in software.

> but I also think we could
> do an OpenGL backend, an OpenGL|ES backend, and possibly a Direct3d
> backend if there were a reason to do one.
>   

We already have this on the cairo level. You can render by using OpenGL
using the Glitz backend. You can render hw-accelerated using the Xlib
backend (which uses XRender). On windows, it uses a GDI backend. IMHO
one of the biggest points of a canvas as a next gen widget system is
that lots of window-system-dependent stuff isn't needed in canvas items
anymore (in contrast to the GnomeCanvasItem::map stuff).

> I've been putting some thought into the idea of a GPU-based GTK, and
> when Havoc first mentioned going the route of having a canvas-based
> widget system I became instantly interested in that because I thought it
> was the perfect opportunity to go the GPU route.
>   

Well, isn't the "right" way to go the cairo path and make the
communication of cairo and the GPU faster (that's "improve Xrender, the
drivers etc.")? As this needs to be improved for a "GPU based GTK"
anyway you won't get any advantage by adding this new level of "platform
independence" to GTK (which is already available in cairo).

Unfortunately I'm not completely into the current state of
hardware-accelerated cairo, but that information should be easy to collect.

Regards,
  Sven

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Havoc Pennington]

Marco Pesenti Gritti wrote:
> There is something which bothers me though. Support for some units, 
> points for example, would require floating points measures. And I 
> suspect we don't want to do layout in floating point (instability 
> issues). Mozilla converts css units in twips (an arbitrary integer unit, 
> 1/20 of a point). That's a way to go about it I guess, though it 
> requires conversions it in the canvas items. Better ideas?
> 

I agree that it would be really good to avoid floating point. Pixels are 
by far the most intuitive thing for people using or writing items, too 
(since as you say they avoid having to multiply everything). Pango does 
have the precedent though and for convenience we could just use the same 
units as Pango.

Maybe there's some way to make this optional, for example items that 
feel they can do something useful with sub-pixel sizes could implement 
an interface that did the size negotiation in sub-pixels. The default 
implementation of the sub-pixel size negotiation methods would call the 
whole pixels one, and the default implementation of the whole-pixels 
methods would call the sub-pixels one and round off. If you didn't 
override either one it would break badly, but don't do that then ;-)
all items would have to implement one or the other but not both.

One downside of doubles is simply the extra memory usage when storing 
coordinates; I think keeping the abstract base class for items and most 
common concrete classes as small as possible is a nice win. I'd like to 
see items be "lighter" than GtkWidget, in almost any of the usage 
scenarios (widget core or drawing api or other).

Havoc

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Cody Russell]

On Thu, 2007-04-19 at 18:51 +0200, Carlos Garnacho wrote:
> There have been several discussions about getting a canvas into GTK+,
> being the last one in the GTK+ meeting at Fosdem [2], where one of the
> conclusions was that we needed to gather the candidates on one side
> and
> the desired feature set for a GtkCanvas on another.
> - Integrate tightly GTK+ and the canvas, even making GtkWidgets
> specialized canvas elements drawn with a certain layout in a canvas,
> see
> Havoc's proposal [3]
> 
> Thoughts? Opinions? 

This is awesome.  I want to propose another thing, which I think is
especially worth considering if we move in the direction of implementing
widgets and layouts using the canvas:

I'd like the canvas system to be generalized enough that we can have
multiple implementations of it, in the same way that GDK allows us to
port to Win32 or MacOSX.  In particular, I think we could have an
implementation that is much like what most of the canvases are doing
today where everything is software rendered.. but I also think we could
do an OpenGL backend, an OpenGL|ES backend, and possibly a Direct3d
backend if there were a reason to do one.

I've been putting some thought into the idea of a GPU-based GTK, and
when Havoc first mentioned going the route of having a canvas-based
widget system I became instantly interested in that because I thought it
was the perfect opportunity to go the GPU route.

/ Cody

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Marco Pesenti Gritti]

On 4/19/07, Havoc Pennington <[EMAIL PROTECTED]> wrote:


Marco Pesenti Gritti wrote:
> * Key navigation (which is obviously also a prerequisite for a11y)

I'd add to this bullet "anything GtkWidget has that HippoCanvasItem does
not" - basically HippoCanvas is the "GtkWidget/GtkContainer replacement"
school of canvas thought.



Yeah.


* Ability to set a global scaling factor for the canvas and support for
> units.

Would this require modifying individual canvas items, or can the
HippoCanvas widget just transform the cairo_t it passes to the root item
(and also transform event coords of course)



I don't think it would require modifying items (embedded widgets being the
exception, in their current incarnation at least). cairo_t and events coords
transformations should do it.

There is something which bothers me though. Support for some units, points
for example, would require floating points measures. And I suspect we don't
want to do layout in floating point (instability issues). Mozilla converts
css units in twips (an arbitrary integer unit, 1/20 of a point). That's a
way to go about it I guess, though it requires conversions it in the canvas
items. Better ideas?

Marco
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Marco Pesenti Gritti]

On 4/19/07, Havoc Pennington <[EMAIL PROTECTED]> wrote:


Hi,

Carlos Garnacho wrote:
> First of all we need to specify the feature requirements for the
> canvas.

I'd step back first and do use-cases instead, and also talk about at a
high level what the canvas is for and when it would be used, i.e.:

  - when is a canvas item used vs. a widget? what current widgets would
be "replicated" as canvas items?
  - when is a canvas used vs. just drawing to a drawable with Cairo and
Pango?
  - is the canvas essentially a fixed-up replacement for
GtkWidget/GtkContainer (the GTK widget core) or does it have some
other purpose? If it has another purpose, what is it?
  - can a list of use cases be spelled out?
  - how are existing canvases being used? which apps seem to be
using canvases and why and for what?

I bet everyone would think more clearly if we put a bullet in the word
"canvas" and instead thought about "next-gen widget system core" or
"simplified drawing API" or something of that nature. If you start
thinking this way, perhaps there's even more than one new API that's
needed, i.e. maybe there's a next-gen widget core, but *also* a
simplified drawing API used to *write* complex widgets/canvas-items.
I don't know.

The word "canvas" is especially misleading because GnomeCanvas is such a
bad model; the big problems GnomeCanvas used to solve no longer exist,
so the GnomeCanvas design really has little or nothing to do with
anything. GnomeCanvas was based on TkCanvas, which has even less to
offer as a model I'd say.




I can think about 3 main uses cases:

1 Free form views(html like).
2 Make it easier to implement complex controls (more powerful drawing API)
3 Next generation controls framework (gtk replacement)

In Sugar we are going to use hippo for 1 and probably for 2 (the concern
there being the lack of accessibility support). We considered using it for 3
but dropped the idea because it would require resources we don't have and
break compatibility with gtk.

Marco
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Havoc Pennington]

Marco Pesenti Gritti wrote:
> * Key navigation (which is obviously also a prerequisite for a11y)

I'd add to this bullet "anything GtkWidget has that HippoCanvasItem does 
not" - basically HippoCanvas is the "GtkWidget/GtkContainer replacement" 
school of canvas thought.

> * Ability to set a global scaling factor for the canvas and support for 
> units.

Would this require modifying individual canvas items, or can the 
HippoCanvas widget just transform the cairo_t it passes to the root item 
(and also transform event coords of course)

Havoc

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Havoc Pennington]

Hi,

Carlos Garnacho wrote:
> First of all we need to specify the feature requirements for the  
> canvas.

I'd step back first and do use-cases instead, and also talk about at a 
high level what the canvas is for and when it would be used, i.e.:

  - when is a canvas item used vs. a widget? what current widgets would
be "replicated" as canvas items?
  - when is a canvas used vs. just drawing to a drawable with Cairo and
Pango?
  - is the canvas essentially a fixed-up replacement for
GtkWidget/GtkContainer (the GTK widget core) or does it have some
other purpose? If it has another purpose, what is it?
  - can a list of use cases be spelled out?
  - how are existing canvases being used? which apps seem to be
using canvases and why and for what?

I bet everyone would think more clearly if we put a bullet in the word 
"canvas" and instead thought about "next-gen widget system core" or 
"simplified drawing API" or something of that nature. If you start 
thinking this way, perhaps there's even more than one new API that's 
needed, i.e. maybe there's a next-gen widget core, but *also* a 
simplified drawing API used to *write* complex widgets/canvas-items.
I don't know.

The word "canvas" is especially misleading because GnomeCanvas is such a 
bad model; the big problems GnomeCanvas used to solve no longer exist, 
so the GnomeCanvas design really has little or nothing to do with 
anything. GnomeCanvas was based on TkCanvas, which has even less to 
offer as a model I'd say.

Havoc

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkCanvas requirements?

[Marco Pesenti Gritti]

On 4/19/07, Carlos Garnacho <[EMAIL PROTECTED]> wrote:


Hi all!,

After reading Tim's mail about volunteer tasks [1], I've bitten the
bullet and will try to help out fostering the GtkCanvas discussion, so
here it goes!

There have been several discussions about getting a canvas into GTK+,
being the last one in the GTK+ meeting at Fosdem [2], where one of the
conclusions was that we needed to gather the candidates on one side and
the desired feature set for a GtkCanvas on another.

First of all we need to specify the feature requirements for the
canvas. The following is a list of features I think we should
consider, hope it's a good start, please add to it if there are others:

- GTK+ suitable API.
- a11y support.
- Model/View split.
- Size negociation, height for width, width for height and natural size.
- object shapes, collision detection.
- animation framework (perhaps should be more tied to GTK+, GtkTimeLine
maybe?).
- get the offscreen rendering patch in.
- GtkPrint* integration.
- grouping/ungrouping.
- extensibility, being able to create new canvas elements with little
effort.
- DnD support.
- Integrate tightly GTK+ and the canvas, even making GtkWidgets
specialized canvas elements drawn with a certain layout in a canvas, see
Havoc's proposal [3]




A couple of features which we are really missing in hippo-canvas:

* Key navigation (which is obviously also a prerequisite for a11y)
* Ability to set a global scaling factor for the canvas and support for
units.

Marco
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GtkCanvas requirements?

[Carlos Garnacho]

Hi all!,

After reading Tim's mail about volunteer tasks [1], I've bitten the
bullet and will try to help out fostering the GtkCanvas discussion, so
here it goes!

There have been several discussions about getting a canvas into GTK+,
being the last one in the GTK+ meeting at Fosdem [2], where one of the
conclusions was that we needed to gather the candidates on one side and
the desired feature set for a GtkCanvas on another.

First of all we need to specify the feature requirements for the  
canvas. The following is a list of features I think we should  
consider, hope it's a good start, please add to it if there are others:

- GTK+ suitable API.
- a11y support.
- Model/View split.
- Size negociation, height for width, width for height and natural size.
- object shapes, collision detection.
- animation framework (perhaps should be more tied to GTK+, GtkTimeLine
maybe?).
- get the offscreen rendering patch in.
- GtkPrint* integration.
- grouping/ungrouping.
- extensibility, being able to create new canvas elements with little
effort.
- DnD support.
- Integrate tightly GTK+ and the canvas, even making GtkWidgets
specialized canvas elements drawn with a certain layout in a canvas, see
Havoc's proposal [3]

Thoughts? Opinions?

Regards,
   Carlos


[1]
http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00058.html
[2]
http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg1.html
[3]
http://mail.gnome.org/archives/gtk-devel-list/2006-August/msg00168.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list