Guillaume Laurent On GTK And The New Inti

KS writes: "Old time GNOME hacker and Slashdot familiar Guillaume Laurent has finally written up an explanation on why he left the GTK-- project. In summary, he disagrees with some of the fundamental features of GTK-- but sees a bright future for Red Hat's Inti. I don't know why but I always find these sorts of things eye opening." Update: 08/10 02:50 PM by H :Guillaume wrote me asking me to mention the an update to the story.

Comments

I completely agree...

[weisserw]

A long, long time ago, in a university far, far away, I wrote my own GTK-C++ wrapper, titled "ObjGTK+", for many of the same reasons Guillaume mentions. The goal of my framework was to be extremely clear and concise, be well documented, and in general be focused towards making the developer feel happy, which I felt Gtk-- was not. As an example, here's "Hello, World" in ObjGTK+:

#include &ltobjgtk.h&gt

class MainWin : public Window
{
public:
MainWin();
gint OnDeleteEvent(void);
void OnHelloButtonClicked(void);

private:
Button *hello_button;

};

MainWin::MainWin()
{
SetupTable(3, 3);

SetTitle("Hello, World");
SetUSize(300, 150);
SetPosition(GTK_WIN_POS_CENTER);

hello_button = new Button("Hello!");
hello_button->ConnectClicked(CALLBACK(OnHelloButto nClicked, this));

Add(hello_button, 1, 2, 1, 2);
}

gint MainWin::OnDeleteEvent(void)
{
OG_Quit();
return FALSE;
}

void MainWin::OnHelloButtonClicked(void)
{
g_message("Hello!");
}

int main(int argc, char *argv[])
{
OG_Init(&argc, &argv);

MainWin *mainwin = new MainWin;
mainwin->Show();

OG_Main();

return(0);
}

Anyway, as soon as this got on Freshmeat, I received some responses (a first!), some encouraging (including some w/ patches, etc.), and one from Karl admonishing me for duplicating his work and urging me to give up ObjGTK and join the Gtk-- project. Now, Karl was very courteous and he did have some points -- a lot of my complaints were really stylistic issues which could presumably be fixed, and Gtk-- had some features which I could not easily duplicate (at the time they were starting to adopt libsigc++, which Guillaume apparently thinks is badly written, but regardless was a very useful idea which worked perfectly in this context. They also had the aforementioned stack-heap duality, whereas all my widgets were on the heap. The implementation of this was so awful I can barely describe it, let alone duplicate it). ObjGTK, although it was fully documented and somewhat useful, was incomplete (hey, I had only been working on it for two weeks), and Gtk-- had classes for almost every GTK+ type and then some. And so after a few such e-mails, I removed ObjGTK from the net and subscribed to the Gtk-- mailing list.

At this point my C++-wrapper development in Linux was pretty much over. I observed the mailing list for a couple of weeks, decided that the first thing I wanted to do was work on the documentation (at this point Gtk-- had no reference documentation and a couple of short programs acting as a tutorial), and quickly foundered. The source was very hard to work through. The headers seemed to be in three places at once, and the methods themselves were sometimes designed so circumlocutiously that it was almost impossible to tell what they did. It was hard to separate the "real" code which I was supposed to be writing from the code which was auto-generated from the GTK+ header files. And, my naive intentions of "fixing" the style issues were undoable; Gtk--'s conventions were simply too deeply rooted and too at-odds with my "simple"
style of programming.

My last run-in with Linux GUI programming was when I had the urge to continue working with an old program which had a GUI interface. I had originally written it in GTK+, then ported it to ObjGTK+ as a test of the latter's capabilities. Now since ObjGTK was dead, I figured the next logical step would be to re-write it in Gtk--. I downloaded the latest libsigc++ and libgtkmm, and got cracking. The first thing I started to write was the toolbar code. I scanned the Gtk-- documentation, found some methods which seemed appropriate, and started writing. It didn't compile because the methods didn't seem to exist. Flummoxed, I sent a message to the Gtk-- mailing list, and recieved a reply from Karl stating that yes, those methods didn't exist anymore, and giving me an example of the "better" way to write toolbar code, which was basically about 50 lines of horrible template code (in contrast to 40 or so lines of GTK+ code, or 20 of ObjGTK).

That was the last straw for me...not because of the bad documentation or the weird style standards, but because of how much this situation reminded me of the chapter in the "UNIX Hater's Handbook" where the UNIX style (make it easy to program) was contrasted with the Lisp style (make it easy to use). In my mind, Karl had become too obsessed with keeping to his academic theoretical perfection, and had disregarded the thing which make an API worthwhile, namely usability.

Looking back I suppose one could see Gtk-- as a shame, a deplorable situation that should never have happened. Personally, I disagree. When I worked with QT, I found it easy to use but I thought their pre-processor approach was terrible. Libsigc++ was a much more elegant solution to the problem which we have Karl to thank for. Likewise, I heavily disagree with another poster here who claimed that pointers are better than references. Pointers create unsafe interfaces, whereas with a reference you are always guaranteed to be passing an object which actually exists. ObjGTK+ used pointers exclusively, and if I re-did it today I would definitely change that.

I look forward to working with Inti; from the descriptions I've read it sounds like a good balance. I'm glad that it's there now since I no longer have the kind of free time I had in college to work on Open Source projects. Maybe soon I'll reorganize my schedule, subscribe to the Inti mailing list and start pestering them with stylistic issues :-).

-W.W.

FLTK

[joss]

If you're writing GUI apps in C++, fltk is the way to go. I've used X, motif, MFC, GTK, Qt, Java Swing, and god knows what else and the only pleasureable experience was with FLTK. It's very fast, very light, very simple, just lets you get on with it.

Qt was pretty good - close second, but it's not LGPL and you need to pay for the windows version.
Fltk is just cleaner. MFC was the worst, closely followed by swing.

Re:inti type safety..

[Sneakums]

from the looks of inti, signals are still c style callbacks with no type checking?

No.

Looking at the headers available at http://sources.redhat.com/inti/inti-manual/ I see that each class member representing a signal is a SignalProxy, which seems to be quite like the signalling facilities provided by libsigc++. Looking at the definitition of SignalProxy, its connect method is parameterized for both the type of the signalled object and the member being connected to.

--
"Where, where is the town? Now, it's nothing but flowers!"

Re:Reinventing QT ...

[bero-rh]

I don't think Red Hat will ever be happy until Qt and the whole KDE project is dead

Not quite true.
While we're not exactly the biggest supporters of KDE and Qt, we do contribute to them, and we're including them.

There's no point in the whole KDE/GNOME flamewars.
Both have their good and bad points and nice applications (I guess most people who are not fanatics of either one are using a couple of GNOME applications from KDE or vice versa) - so why not give users the choice?

This includes giving C++ programmers the choice to have a sane interface to gtk+ (such as Inti). It's not an attempt to kill of Qt.

(FYI: Yes, I have programmed in both, prefer Qt, and think gtk+ needs a more Qt'ish API for people who like C++.)