Re: gtk_widget_draw()

[Alexander Larsson <alexl redhat com>]

On Fri, 2010-08-20 at 03:09 +0200, Benjamin Otte wrote: 
> On Thu, Aug 19, 2010 at 10:08 AM, Alexander Larsson <alexl redhat com> wrote:
> > The problem with no-window widgets is not really for the no-window
> > widget, but rather that all parents must have special expose code that
> > chains to the no-window widgets. If we want to clean up the drawing code
> > this is kinda ugly.
> >
> I think this is a crucial question we need to answer about future GTK/GDK:
> Who should be responsible for chaining up to children?
> (Note that this question is not just interesting for drawing, but also
> relevant for event handling.)
> 
> Currently everybody does at most half of this job: GDK does it for
> windows, GTK does it for drawing on no-window widgets (with
> gtk_container_propagate_expose()). GtkWindow does it for key presses.

Well, no-window widgets merely handle drawing, not events, those are
still handled by gdk (via input-only windows).

The reason for no-window widgets are twofold:

1) Allow "transparent widgets, i.e. those that paint over their parent.
2) Avoid use of visible native windows as much as possible, as these
cause ugly resizing behaviour.

Although it also gets you:

3) Somewhat easier to code draw-only widgets. (i.e. no need for
realize/unrealize or any other window handling)

2 is fixed with csw and 1 is simple to add. With a remove of no-window
widgets we make container widgets simpler, but widgets like in 3
somewhat harder. I think that can be fixed by better default
realize/unrealize implementations though.

So, imho no-window widgets removal is an obvious candidate for
simplification when we have the chance.

> In my ideal world, the containers are responsible for bubbling up
> drawing commands and events. For gtk_widget_draw(), this is pretty
> much a requirement. Otherwise we'd need to duplicate the GDK
> functionality into that function (just lik gtk_widget_get_snapshot()
> does now).
> Also, relegaing this job to Gtk allows much more flexibility in
> creating widgets because one is not bound by the limitations of GDK as
> one translates events oneself. So things like Coverflows get possible.

A different semantics for events (maybe the bubble down then up again
style from the web world) is a nice idea. However it would be a break in
event handling that is quite large. Additionally it puts a lot of load
on widgets, as each widget now have the full responsibility to manage
the event semantics required for its children (deliver enter/leave
events with the right detail and crossing mode, know of global state
such as grabs and foucs, etc). This is the kind of stuff it took me a
year to fix for the gdk even propagator, not something you want to push
on widget authors.

I think the offscreen window model we have for event translation is much
simpler and something mere mortals could possibly get right. It lets you
define additional "parent-child" links and coordinate transformations,
the rest is handled by gdk.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a fast talking Jewish jungle king with a winning smile and a way with the 
ladies. She's a vivacious gypsy former first lady from beyond the grave. They 
fight crime!