Re: [gtkmm] Talk about a major rewrite



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.







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]