Re: gtk_widget_draw()

[Havoc Pennington <hp pobox com>]

Hi,

On Fri, Aug 20, 2010 at 5:22 PM, Alexander Larsson <alexl redhat com> wrote:
> If I were to do something like that I'd keep gtk3 approximately as it
> now takes shape (i.e. cleanup but mostly compatible). Then create a
> completely new toolkit with a different name, based on the gtk stack
> (i.e. cairo, glib, gio, pango, etc). This is kinda what clutter does, ,
> although clutter is not really a full toolkit (no toplevel handling, no
> file dialogs, no printing, no dnd, etc, etc).
>
> I don't think its worth it though. Even when reusing the lower parts of
> the stack we're talking many man-years of work, and I think the "linux
> desktop" could spend that effort better on other things.

I think the path to this is really pretty clear. It's already been
shown by Clutter and HippoCanvas among others, both of which embed GTK
widgets and have been used to make real apps. Hell, other examples are
WebKit, XUL, even GnomeCanvas.

You do the "scene graph" lib and you use GTK for the "hard widgets"
and "toolkit stuff". There's a model where you put GtkWidget inside
the canvas, and there's a model where you put the canvas inside a
GtkWidget, or do both. Whichever way, GTK can be used for things like
input methods and DND and toplevel windows.

There's a path of gradual refactoring to strip duplication between the
Clutter/HippoCanvas/whatever thing and GTK itself, most of which makes
nice sense anyway because for both GtkWidget and subclasses, and
ClutterActor and subclasses, and HippoCanvasItem and subclasses, or
whatever, all those things are better off if they are "just a canvas"
and minimize entanglements with the window-system-ish stuff.

Saying "completely new toolkit" leads to reimplementing really big
hard things such as: keymap handling, input methods, themes, TreeView,
TextView, even Entry, DND, etc. etc. all of which is very solid in
GTK+ already. It should be possible to get to scene graph without
redoing any of that. Actually, it is possible. It's been done in
specific canvasy-thing-using apps.

On the Clutter front I'd still like to see the ClutterBackend
replaceable at runtime so you could basically put GTK in there or your
compositing manager in there, and avoid Clutter's attempts to do its
own Xlib things. That'd be a nice step forward.

I don't think any of this is truly hard or even a ton of work. What's
a ton of work is the point where you try to go GTK+ 4 and "force" one
of the specific scene graphy things. Especially if that's done before
some of the tough problems have de facto answers already working.

But in terms of practical benefits to apps you can get really really
far by just refactoring GTK+ and Clutter and whatever to "play nice"
with each other by avoiding these assumptions about who owns the
window system abstraction, master clock paint loop, layout idle, etc.
- and to some extent, keeping scene graphs from creeping up into
trying to become full toolkits is helpful, if instead GTK's facilities
such as themes and input methods can work well for non-widgets, that's
a big win. Lots of these problems are already solved in a hacky way,
just not in a clean way.

One concrete thing GTK can do is work with interfaces rather than
GtkWidget for APIs such as DND or input methods or whatever it is, so
that an actor/item class can implement the interface too.

A harder, but nice thing GTK could do is to work toward GDK being less
GTK-specific; this cleanup work definitely is on that path I'd say.
But think about Clutter basically targeting GDK, and on the flip side
(and blocking on a future where GL can be assumed), think about GTK
making use of COGL.

A way to think about it is that GTK could become several distinct
features, possibly in separate libs: window system abstraction;
little-to-do-with-widget/actor/item stuff such as input methods,
keyboard handling, GtkAction, etc. ; GtkWidget/GtkContainer widget
core (the "widgety scene graph"); and finally a collection of widgets.
I'd add to that, GL system abstraction (i.e. COGL). Oh, and in one of
those buckets should be the paint loop ("master clock") or nobody can
do decent animations.

All I'm saying is I think there's a useful direction to move in that
really doesn't require a huge rewrite. In fact I'd say a new toolkit
is dumb. The evolutionary approach has already been slowly going there
and people cobble stuff together.

If you look at GTK+ and Clutter there may well be a simple practical
problem: no module to put shared code in. Kind of like when
freedesktop.org was started, it was just to solve "ok, gnome and kde
want to share code that does xyz, where the hell would we even keep
that code..."

Dunno. I guess I'm just thinking that the old model of so many
different things making up a "toolkit" is kinda fading, we've seen
important GTK chunks shedding down into Cairo and Pango and GLib and
gdk-pixbuf already, and I'd only expect that to continue, as GTK
gradually evolves toward only being one specific scene graph system
among several, the others mostly less "widgety"

The remainder to shed really is small and can be done in steps.
There's the "give me a toplevel window and events on it" piece that
Clutter's backends and GDK basically do. Then specific facilities such
as input methods, master paint clock, etc. that could be factored out
one at a time.

It sounds a little hard but then I think about replicating some of the
nicer GDK and GTK features that are already working nicely, by
rewriting them for a new toolkit like Clutter, and that sounds pretty
hard too.

Havoc