Re: Canvas shortcomings

[Havoc Pennington <hp redhat com>]

Peter Williams <peter newton cx> writes: 
> 	a. GnomeCanvas needs to be able to contain widgets

There's some upside for the canvas in making the core widget system
more canvas-like, really.

Moving GTK to a render model makes this work a lot better, in at least
two ways:
 - widgets no longer have windows; the only X window is the one for
   the toplevel
 - widget canvas items would work in AA mode

Ideally, widgets and canvas items are pretty much the same thing. 
The canvas has sort of become a mini vector-based widget set, with
people implementing custom widget displays in there, but the problem
is that GTK has APIs such as input methods and GtkBindingSet and
focus handling and so on that require a GtkWidget, not a
GnomeCanvasItem. So doing widget-like things in a canvas is a) painful
and b) usually ends up being a bit broken.

Fixing this is pretty tricky without unacceptable levels of API
hosage. But you can imagine something like breaking most widget
functionality (such as focus handling) out into interfaces so canvas
items can use them, or alternatively, making widgets more like canvas
items so there's no need for a "canvas widget" GTK is just one big
canvas.

I'm guessing we're talking very pipe-dream type of stuff now
though. ;-)

Still, it seems pretty realistic to make the GTK standard widgets no
longer have X windows and use the same render setup as the canvas, and
just those relatively small things would be reasonably big wins.

Don't you want an affine-transformed option menu? You know you do!
;-)

BTW, I think we can remove pretty much all the backing store handling
from GnomeCanvas in 2.0 since it's automatically done by GdkWindow -
would be a good performance/memory enhancement for canvas-based apps.
Someone may well have already done this even.

Havoc