TWITTER UPDATES

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.
• Allow 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 does it...)
• Remove all output windows from widgets that come with GTK+.
• Implement paint clock.
• Profit!

Advantages include:

• 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 huge 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 flexible drawing.
• 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 kept.