Re: GTK+ canvas?

Soeren Sandmann wrote:
A much simpler approach is often to simply walk the model and draw on
a drawing area on every expose event. This gets hard for two reasons:

- you need to handle input on distinct areas corresponding to objects
  in the model.

- you need to handle scrolling

Both of these are solved by a canvas widget which I'd argue is its
main attraction. For the old GnomeCanvas you also had the attraction
of antialiasing/translucency and bezier curves, but not cairo provides

Do keep in mind though that GnomeCanvas is a very, very low bar. As I mentioned in my year-old "canvas notes" mail, based on GnomeCanvas I thought a canvas widget was useless - it was mostly useful as a workaround for GTK 1.2 deficiencies, and most of GNOME stopped using it after GTK 2.0.

A canvas widget _can_ do a lot more, much of it useful.

The difference is in how input is handled. During the expose handling,
the application is not only drawing stuff, it is also setting input

Very clever!

I believe this 'immediate' mode canvas is a simpler and more efficient
model than retained mode canvases, at least for most non-trivial

It depends on the goals of a "canvas" right - you're thinking of it as "drawing area plus hit testing" while it can be thought of as solving a wider set of problems.

In particular I think of it as a more flexible sort of widget system more like HTML or Flash or XAML, in which the existing more rigid gtkwidget/gtkcontainer framework could be embedded.

I wonder if this "immediate mode" model is interesting as either a layer below a more complex retained-mode canvas, or as a particular kind of item (widget?) inside a more complex canvas.

But also worth considering is essentially adding hit testing to GtkDrawingArea and leaving that as the "canvas" in gtk, that would be one way to avoid unlimited scope creep...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]