GTK+ becomes a canvas

by havoc

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)