[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: GTK+ canvas?
From:       Havoc Pennington <hp () redhat ! com>
Date:       2006-08-31 18:51:05
Message-ID: 44F72F99.8010209 () redhat ! com
[Download RAW message or body]

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
> this.

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
> regions. 

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
> applications.

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...

Havoc

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]