Havoc's Blog

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.

(This post was originally found at http://log.ometer.com/2010-10.html#18)