Hi, On Fri, Aug 20, 2010 at 5:22 PM, Alexander Larsson <al...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list