Re: [gtkmm] Talk about a major rewrite

[Michael Babcock <mbabcock la creatureshop henson com>]

Paul Davis wrote:
[snip]
> then leave. gtkmm is a wrapper for GTK+ so that C++ programmers can
> use GTK with C++ idioms. if you think GTK+ is a piece of crap, then
> don't use gtkmm.

I'll probably regret this, but... I think the GTK design is a piece of 
crap (though I usually try to be more diplomatic), and I am using gtkmm. 
The problem with the "leave" suggestion is, where do we go? 
Unfortunately there really is no good answer, and this is why these 
debates/flamewars come up from time to time over the years.

I sympathize with the P. Christeas's frustration, but think it is being 
misdirected at gtkmm. I think gtkmm is about the best C++ wrapper for 
gtk that could be written. The extra layer does add some confusion and 
compounds documentation weaknesses, but generally I've found gtkmm2 to 
be very well done. I also like libsigc++.

But I don't like programming GUIs with gtkmm, and I usually come to 
blame what I consider poor design of the underlying gtk widget library. 
So, as Murray pointed out, this is really off-topic for gtkmm, but 
presumably we have people here interested in GUI programming with C++, 
so this may be as good a place as any to keep these rants contained.

Maybe I'm just being too picky, and I am picky when it comes to 
programming, but it is striking to me that I don't feel this almost 
constant frustration with any other library that I regularly use, such 
as the C++ standard library, Unix networking functions, 3D scene graph 
libraries, OpenGL, sound libraries, POSIX threads, etc. In all other 
cases I can (eventually) perceive an underlying concept behind the 
design, appreciate the designer's work and implement my program using 
their library. With gtk I am mostly cursing the simplistic design and 
trying to find workarounds to do what I want.

So why do I use it? Because while I think the API design is crap, many 
of the individual widgets are full featured (from a user point of view) 
and implemented well. It is widely used, so implementation bugs get 
fixed by someone else. My own favorite toolkit was Fresco, whose 
designers I believe knew what they were doing, but it never became 
popular, so while the framework is good, the individual widgets are not 
competitive with Qt, Gtk, Mac, or Windows from a user perspective.

So basically I have two bad choices, use Fresco and spend most of my 
time adding features to the basic GUI widgets that everyone expects, or 
use Gtk and have to tear my hair out when I need more advanced 
functionality than the stock widgets provide (and which I know would be 
simply and elegantly done in Fresco). (Others, such as Qt, don't provide 
any real power over Gtk like Fresco does, so there doesn't seem to be 
any point in bothering to switch to it at this point, after I've used 
gtkmm for several years.) Perhap P. Christeas suggestion has merit, copy 
and paste the Gtk widget implementations into the Fresco framework, 
though I'm afraid it will be a lot more work than that.

I should say that Gtk 2.0 did fix a couple of my complaints, and there 
are some good bits in the gtk world. Owen Taylor seems to know his 
stuff, and Pango, libart, and drag-and-drop seem well-conceived. Perhaps 
Glib provides a good C object system, though I don't know or care much 
about it. But Gdk and Gtk are seriously flawed. I could write long 
essays about why but what's the point? Read the Fresco white papers. Try 
to write a custom gtk widget and then realize you have to implement 
about 5 different versions with 7 different renderers to actually use it 
throughout your gtk program, etc etc. Perhaps Gtk 3.0 will surprise me 
with a complete redesign of the widget class hierarchy. But as that is 
what it would take, a simple implementation patch to gtk won't help.

I'd like to attempt to take step back from all the details and ask: how 
will we be programming user interfaces 5 or 10 years from now? Frankly I 
can't believe it will still be this clumsy. About 4 years ago I wrote an 
article for Linux Journal giving an overview of the various GUI toolkits 
available for Linux. I think I concluded that I didn't like any of them 
:). So obviously I am a bit frustrated that nothing has really changed. 
Perhaps a new model based on the xml, layout and compositing work of the 
Mozilla project will lower the barrier to creating usable, flexible 
interfaces. Both the traditional Mac and Windows APIs, which have 
historically been as bad or worse than Gtk, are being replaced with Mac 
OS X and Windows .net. I haven't looked at them yet, perhaps they offer 
something better to emulate. I don't know. But I do know that there is 
nothing fundamental about a graphical user interface that should make it 
so much more difficult to implement than the other parts of the program, 
and in 10 years we will be using the model that provides this ease.