GTK+ becomes a canvas
Wishing I could be at the GTK+ hackfest this week.
Hoping the heroes there will discuss converting GTK+ to a nice canvas
library. I think it’s a couple person-months of
work… but it may not be work there’s time to do for 3.0.
- Implement a “hovered” or “contains-pointer” property to replace
enter/leave notify event in most cases.
no-window widgets to get events (this is a big API headache that
could use much discussion)
- Remove all input-only windows from widgets that come with GTK+.
Implement a way to scroll and clip without a GdkWindow. (Not yet
investigated. Not too hard… client-side GdkWindow already
- Remove all output windows from widgets that come with GTK+.
- Implement paint clock.
Deletes a bunch of code from GTK widget implementations
(realizing/unrealizing GdkWindow, translating window coords to widget
coords, tracking enter/leave state, etc.).
GdkWindow is freaking
while GtkWidget is not.
- Recursive rather than “global knowledge” event and redraw system
mixes more nicely with other toolkits (e.g. clutter-gtk
setup). Destroy gtkmain.c
Can do a GDK backend on COGL, tuned for a clutter-gtk combo, that does
not have to mess with child windows — only implement the toplevel,
similar to Clutter backends. Recent Wayland backend for Clutter was
much easier than a GDK backend would have been. This is bad because
GDK has important code (i18n, multihead, multidevice, drag and drop,
etc.) that should not be lost just to use proper hardware rendering.
Part of the appeal of Clutter is ease of doing a custom backend.
(Food for thought: Clutter got it right by having the platform
portability layer be “implement the toplevel window” instead of
“implement a window system.”)
Can add GtkRectangle, GtkEllipse, and other “canvasy“
primitives and GTK+ would be a good “canvas.” No more need
to invent a new widget system based on “canvas items” just to get more
Straightforward future directions would allow widgets to have a
paint/pick transform similar to Clutter (but 2D); support widgets
drawing outside their allocation; support 0x0 allocations; and
generally remove limitations inspired by GdkWindow.
Another future direction is to always have GtkWidget delegate to parent,
rather than using global state.
I’m sure in-person discussions can improve on this.
An important point maybe is that lots of Clutter users are doing
their own backend or can use an “embedded” custom setup
rather than one that could be the default desktop GTK+. That’s why
it’s useful to strip GdkWindow out of all the default non-toplevel
widgets, even though certain widgets in a full desktop will still have
windows and window widgets will still have to be supported during 3.x
on a default desktop build.
An overall goal in my mind is to allow apps to switch to proper
hardware rendering, without rewriting the app or regressing on all the
“solutions to hard problems” GTK+ code that ought to be
(This post was originally found at http://log.ometer.com/2010–10.html#18)