At last week's Guadec meeting, Kristian Rietveld delivered the GTK+ "state of the union" report. GTK+ is the multi-platform toolkit behind a number of popular applications and, perhaps most well known, the Gnome Desktop environment for Linux. Read the full report here.
To read all comments associated with this story, please click here.
Member since:2007-05-12
In my humble opinion this is yet another example that object-oriented programming in C is a bad idea and that when you start doing this, it is more than time to start using C++...
True, imo too. There is another option too - the "D" programming language. It's a much-cleaner and simpler follow-on to C++. Uses modules instead of header files, has built-in garbage-collection and many more good features. It *also* has very extensive built-in testing facilities.
Edited 2008-07-14 11:02 UTC
Member since:2005-11-18
D is really nice, but the standard library situation should be solved (with one, rather than two competing standard libraries), and the language should become stable (there are many useful additions in the D 2.0 spec, that is still in progress).
Member since:2005-07-06
I know this sounds stupid, but why not Objective-C? I've looked through it, and its a damn site nicer to use and look at than C++. Its well supported and developed for, increasing numbers are taking an interest in it as the user base grows.
Right now Objective-C 2.0 brings garbage collection and many other features. I know it'll take a while, but compared to C++, its the lesser of two evils at the moment.
Member since:2008-07-14
With Objective C it would not be easy to have bindings for static typed languages. Also the Smalltalk-style syntax doesn't map very well to most other languages.
I think GTK+ 3.0 should be implemented in Vala (at least partially). It's designed for the GObject type system and results in the same ABI as C libraries.
Member since:2005-08-12
Nicer to look at? You're kidding, right? 
It takes two of the ugliest known languages known to man and mashes them together.
They each have features the other doesn't, they both have things one does better than the other. Speaking as a C++ programmer, there are many things I can't live without, and while I realize the same may be true for an Objective-C programmer, my side wins because there are by far more stubborn C++ programmers. :-D
Member since:2006-05-09
What about Vala?
What about written a real Vala compiler that receives as input a Vala source code and outputs a binary GTK+ compliant?
Vala is a very nice programming language and is GTK+ centric, so will model everything à la GTK+... no wrappers, idioms or verbosity needed.
Member since:
2006-01-02
It's good to see so much activity in the GTK+ area, but something really disturbed me: the item they mention the most for GTK+3 is making structure fields private i.e. the app uses only accessor functions and not directly the member data fields in structures.
Of course this is a very good idea -- in fact it is more than that -- it is vital in any object-oriented framework. Indeed, if structure fields are publically exposed to apps, then it is impossible to rework them internally without breaking these apps. Which often makes implementation changes impossible.
So what really disturbs me is that GTK+ somehow manage to make it into year 2008 with publich structure fields. Then again, the C language doesn't help them at all with making these private... since it wasn't designed for object-oriented programming in the first place.
In my humble opinion this is yet another example that object-oriented programming in C is a bad idea and that when you start doing this, it is more than time to start using C++... in fact I can hardly remember the reason why GTK and GNOME still refuse to use at least some features from C++. The two arguments mentioned are a) "C++ libraries are harder to make bindings for" and b) "C++ doesn't have a standard ABI". Well, as has often been said, these arguments are not convincing: a) there exists Qt bindings to a plethora of languages, and b) since each released distro sticks to one compiler version (like "gcc 4.2.3") it doesn't matter if the C++ ABI is not always preserved across versions.