Often I complain that GTK+ documentation (non-reference) is non-existent. The few GTK+ books that were ever written are now old and most of their included source code does not even compile anymore. All hail "Foundations of GTK+ Development" by Andrew Krause.
To read all comments associated with this story, please click here.
Member since:2005-07-15
>I would probably use GTKMM, the C++ wrapper framework.
i agree. Sadly there is no Gtkmm book available and i prefer learning with a book.
Also a strong argument against Gtkmm, at least for me, is the missing feature to connect automatically the signals defined with Glade.
>Of course, these days I prefer Java and .NET. Coding for VM's seems to be the rage, you know.
That's the nice thing about Gtk+. You don't have to code in C, you can code in C++(gtkmm), Python(PyGTK), Java(java-gnome), C#(Gtk#),...
That's really great and it always remembers me about a statement from Owen Taylor (RedHat):
"And of course, the number 1 tip for GTK+ programming is: Don't use C; In my opinion, C is a library programming language not an app programming language."
There is only one problem in my view. This works really well as long as you use compiler-languages (C, C++, Java with gcj,...). But if people start using Python, Java, Mono and other interpreter- or VM-languages than it becomes really bad for memory usage. Imaging you are using 3 applets, on written in Python, one in Java and one in C# than you have all the time one interpreter and two VMs in the background.
Edited 2007-05-23 15:46
Member since:2005-07-12
Good point.
That makes GTKmm more compelling.
But if one is going to with a higher level VM language, I would go with SWT / Eclipse RCP.
SWT is an API that in turn calls native APIs of three (currently) different native APIs: Win32, MacOSX, and GTK.
Thus, with SWT, you can make GTK native looking Java desktop apps.
Then with Eclipse RCP, you have all the advantages of JFace, the Eclipse workbench and plugin architure (abstractions on top of SWT), and you can use the Visual Editor.
Of course, then you can package your app for Windows and Mac, very easily.
In short, you get great native looking apps, with good performance (it's using native widgets).
As for GTK# - while it's technologically nice, and Miguel and the Mono crew have done an outstanding job - GTK# is extremely dangerous. It's inviting lawsuit, or intimidation and/or extortion from Microsoft. The recent Fortune magazine article, which contains MS's latest patent threats, makes this crystal clear.
Member since:2006-02-06
If you think like that I guess you would really like to hear about Vala
http://vala.paldo.org
it is a programming language designed to be something like a To Gtk+ Translator. It looks a lot like C# and compiles to C Code using Gtk+ (and it compiles rather cleanly, except for a feature or two that needs some weird C code to work)
It is really great and I guess it could use a bigger mindshare right now to be useful to its full extent.
Member since:2005-07-07
But if people start using Python, Java, Mono and other interpreter- or VM-languages than it becomes really bad for memory usage. Imaging you are using 3 applets, on written in Python, one in Java and one in C# than you have all the time one interpreter and two VMs in the background.
It's actually not that bad. I have mono, java, and python apps running at the same time on a modern machine and it does fine.
Member since:
2005-07-06
It's an older book, but I still like "Developing Linux Application with GTK+ and GDK" by Eric Harlow. It has a very friendly, conversational style, but provides a good overall introduction to GTK+.
My own take on GTK+ development was mixed. I come from a C++/Java background, so I found GTK's semi-object-oriented programming a little strange. I would probably use GTKMM, the C++ wrapper framework. In Windows I preferred MFC C++ development rather than Win32 API C programming.
Of course, these days I prefer Java and .NET. Coding for VM's seems to be the rage, you know. Go Parrot!