Re: rendering-cleanup worries

[Benjamin Otte <otte gnome org>]

After reading this mail I think we pretty much 100% agree on the ideal
world. The hard part is just figuring out how to get there. I see 2
problems with this:
1) developer time to actually implement this for GTK3.
2) keeping the code changes for app developers small.

So if we don't manage to get this for 3.0, can we get it for 3.x? If
so, do we need to prepare 3.0 in ways that make it possible? And if we
don't get it done for 3.0, can we prepare 3.0 so that we can get this
done as easily as possible for 4.0?

On Mon, Aug 23, 2010 at 10:39 PM, Alexander Larsson <alexl redhat com> wrote:
> I don't particularly care if we "break" mozilla or eclipse as they exist
> now. I mean, we already do that just by breaking the abi. Its more that
> I fear that the needs of something more complex like a full desktop with
> panels, systrays, desktops, browser plugins, document object embedding,
> etc. at times do require "weird" stuff in the lower layers to make it
> work. And there is a risk that not allowing "weird" stuff will cause
> problems down the line.
>
I try very hard to talk to people about all these things. And that
includes all the parts that make up a desktop. But the "weird" things
in a desktop usually rely on X11 and not GDK (a very sincere thanks
for that to the KDE guys ;)) and can be solved that way.
I think it was misguided to let GDK be a complete wrapper around X11
instead of a useful sugary layer on top. So I suggest we encourage
poking at libX11 directly if you do stuff that relies on X11
constructs. And then we do a useful abstraction on top that provides
the common requirements as easily as possible. The nice side effect of
that approach is that it's way easier to port to other systems.

> 2) Remove GtkWidget->window.
>
> [...]
>
That's basically what I'm aiming for with my cleanup work and
gtk_widget_draw(). Though as we've talked about it, I'm working on my
fallback plan to honor windows and work with them while they are
there. The nice side effect is that it's something that could be done
step-by-step during GTK 3.x: Slowly make all widgets not have windows
anymore.

> 3) Change the event model
>
>        GdkWindow still deliver "native style" events to the toplevel,
>        but this is converted by GtkWindow or suchlike to a DOM style
>        capture (go down) then bubble (go up) model. This event handling
>        would be done by the widgets, and as such wouldn't look exactly
>        like the current one (no masks, widgets can control how events
>        look like to the lower hierarchy, etc).
>
We do almost have that functionality inside GTK though, don't we? I
mean, the csw work you did is basically doing this whole event
dispatching work on the client side. Or am I missing the boat?
I have never really looked at event dispatching, so I might be way off here.

> However, it would also make porting existing widgets a major endeavor.
> You need to basically redo the whole event and repainting system for the
> more complex widgets like the treeview and textview. It definitely will
> not be the almost-trivial kind of porting changes you've talked about
> before, with the expose to draw() conversion. Although for a typical app
> that just uses widgets it might not be that much of a change.
>
Would it be that complicated? It might involve some work for the more
complex container widgets (the ones with more than 1 child) and the
ones that haven't been touched in ages and do magic with GdkWindows,
like the ones you mentioned. But that's not what most widgets do. And
maybe we could even keep widget->window and make it possible to
transition slowly during GTK 3.x?
Again, I have no idea about the amount of work involved here, but
speaking purely from a rendering POV, it shouldn't involve much work.

Benjamin