Submitted by 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.
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.
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
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).
I think the problem with D is the inclusion of pointer and this will lead to the same type of problem we saw in C++. (personal opinion)
1. D can be directly link to C. So why supporting pointers? If you absolutely need it, where do you need it for GUI programming anyway, you just have to make a C function
2. Programmers will code in D like they did in C. Full of stucts, pointers.
The result will be applications that are no more easier to debug, still suffering from buffer overflow and security holes.
I would probably choose Obj-C, but I don’t have an idea if Apple have patent or IP on it. But if there’s a pointerless D, I’ll probably take this one.
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.
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.
is Qt not bind to Cocoa on OS X? Never tried, but isn’t possible to code OS X application in C,C++ or Obj-C in xcode?
With pure C you can code Carbon applications, but Carbon is outdated. Then there is Objective C++: most of your program will be C++ but the Cocoa calls will be with the Smalltalk-like “Objective-syntax”. Perhaps that’s what Qt does. The Java bindings had difficulties mapping Cocoa to Java and are abandoned now. And even Ruby or Python bindings look strange, like: myObject.setValue_forKey_(u”foo”, u”bar”)
Edited 2008-07-14 15:24 UTC
Vala code does not only compile to GObject/C libraries, the compiler also will create interface files for GObjectIntrospection, which can be used for example from Python to bind GObject libraries at runtime:
http://blogs.gnome.org/johan/2007/11/30/future-of-gnome-language-bi…
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.
I totally disagree that Smalltalk is an ugly language. It’s actually one of the best and most beautiful programming languages together with LISP. But I wouldn’t want to see it mixed with C code. And Objective C has no blocks/closures, which actually are one of the most important features of Smalltalk.
Edited 2008-07-14 16:03 UTC
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 ~A la GTK+… no wrappers, idioms or verbosity needed.
Would be possible, but the current solution with C as an intermediate language has the advantage that you get all C compiler optimizations for free. And it is possible to distribute the generated C source along with the source tarball. So if someone wants to compile the application for his platform he wouldn’t even need the Vala compiler.
Using C as an intermediate language for compiling is not uncommon. For example Eiffel does this, too.
Actually it’s GLib centric.
You can write object oriented applications without any GTK+.
So, do you think is feasible to write the new GTK+ stuff JUST in Vala?
Vala would be in charge of all the plumbing and the developer would not need about anything (that’s the rational behind Vala, of course)
Basically it should be possible, but Vala has still bugs and the syntax is still changing sometimes, it’s not a final version yet. GTK developers would have to tightly cooperate with the Vala developers. But as I understand GTK+ 3.x is not intended as a complete rewrite, but as a major refactoring and extension. In my opinion it would be reasonable to implement new widgets and components in Vala and let the others be plain C until they get replaced at some time. GObject/C and Vala classes happily work together as they are the same.
What about Lua – http://www.lua.org
I’m also a c++ programmer, but i kind of like Lua for some reason, it just seems right.
Lua is a cute scripting language for scriptable applications and games but doesn’t compile to native code.
The open source community thrives on innovation and interesting challenges, which is why there is now talk of GTK+, but one has to wonder whether it wouldn’t make more sense to spend the next three years in bug squashing and polishing mode.
That’s what the current gnome desktop needs from a user’s point of view. A rewrite will be costly, will lead to loss of functionality in some applications in the short term 2-3 years and to the potential disappearance of others.
I think 3-4 years for ABI/API breakage in the gnome world is too short a time. 6-8 years sounds like a more reasonable time frame, that is if they expect any serious uptake by real users in government, education and so forth.
People moving to Linux are not looking for sexy. They are looking for reliable, fast and feature-full desktops. And some of the issues with GTK2 could very well be fixed without breaking ABI/API.
Good luck to them, nonetheless.
Well if done correctly, API/ABI breaks won’t be noticed by the user. Linux, like most other OSes, can have multiple ABI/API incompatible versions of the same library installed. Software that only works with the older ones will be dynamically linked with the older ones rather than the newer ones.
Similar to how you can run GTK1 applications on a modern Linux desktop, it just looks bad.
Of course, that means applications using the deprecated APIs won’t benefit from updates to the newer versions of the library and there will be some added overhead in maintaining a seperate code base for older versions of GTK and performing security fix releases, but it could be well worth it.
Edited 2008-07-14 11:49 UTC
If I read correctly this exactly the plan, I believe 2.16.x will be the last 2.x.x version and will include the deprecated functionality, the first 3.0.x version will be able to install alongside the 2.16.x version and is the same as the 2.16.x vesion without all the deprecated code. So all in all a smooth transition should be possible and if you don’t want to jump you can still use 2.16.x (which is backward compatible in the 2.x.x range), but I think that the most popular software will make the jump very fast.
Introducing a cleaner codebase to the library can actually result in fixed bugs and better performance, in addition to the ability to support new and needed features. Now is not the time to go and polish a turd (GTK2), or at least not as the main focus of the GTK+ community. Certainly development and bugfixing on GTK2 should not cease once work begins on GTK3, however.
“The open source community thrives on innovation and interesting challenges, which is why there is now talk of GTK+, but one has to wonder whether it wouldn’t make more sense to spend the next three years in bug squashing and polishing mode.”
I agree. I’m thinking about two top level OSS GTK apps: Inkscape and Pidgin. Both are pretty good applications, but are still struggling to reach “top of the class”: Pidgin is always chasing protocols (not their fault, of course), while Inkscape’s roadmap still shows a lot of work ahead.
The following scenario: GTK developers moving to an incompatible GTK 3 API and Inkscape/Pidgin having to rewrite most of the applications, losing functionality for a while and they trying to put it back in, seems like an users’ nightmare to me.
And these are just 2 examples, think of the tons of GTK 2 apps.
Edited 2008-07-14 12:56 UTC
Well, in the short run, it’ll be bad, that’s for sure. But in the long run, the developers will have to spend less time on the basics, and be able to take advantage of new capabilities in the framework. Same with KDE. It’s about short-term vs long-term vision…
Yeah, but do you have the manpower? And the issues lagging the projects I mentioned aren’t the “code in 30 minutes” type. Is there a reason to think that a better framework will help problems which are conceptually (intrinsically) more complex?
Same question for KDE 4
It won’t help with the more complex issues, but it’ll give you more time to focus on them, as the more easy ones will become even easier
But yeah, it does depend on the application in question.
True, Inkscape has deep ties to Gtk. However, Inkscape, similar to a lot of other apps, wants to decouple the application logic from the GUI toolkit as much as possible.
Hopefully apps can get to the point where toolkits can be snapped on interchangeably with relatively little pain.
This is a fine idea, except for one detail. Who will perform the labor? If open source developers, who contribute for no reason other than their joy of programming, receive none of the joy but all of the labor, what is the incentive?
It would cripple the resources of any large corporation to replace these many amateurs (translate this literally “for the love of it”) with full-time employees.
There needs to be a better arrangement than “don’t do what you want to do, do what I want you to do.”
Edited 2008-07-14 20:33 UTC
> Then again, the C language doesn’t help
> them at all with making these private…
I think they mean:
now
gtk_foo.h
———
struct gtk_foo {
int something;
};
struct gtk_foo *gtk_foo_create();
int gtk_foo_get_something(struct gtk_foo *);
then
gtk_foo.h
———
struct gtk_foo;
struct gtk_foo *gtk_foo_create();
int gtk_foo_get_something(struct gtk_foo *);
gtk_foo.c
———
struct gtk_foo {
int something;
};
so in pratice this is a way to make field structures private to other files…
Edited 2008-07-15 12:23 UTC
I’m happy people are finally coming up with more solid plans to the future… but this document seems more like a “teaser” than a “trailer” to me… some ideas, some proposals… but in the end, there’s not too much decided.
Some of the technical changes may be good, but will it address performance problems? they mention layout engines, but what is the direction they’re looking for? what problems they want to solve? better yet, what kind of UI paradigm they’re looking for in the future for GNOME?
Even with clutter mentioned, it doesn’t really make obvious the direction they want to take.
I REALLY would like some kid of new HIG proposal and some interface mockups… in the end, that’s what the user understand as “GNOME”–the experience they have with its user interface.
I not really looking forward to a DE with half programs taking a paradigm and each one of the rest trying new approaches… So, it would be nice to starting to look at these thing as soon as possible, so the community can synchronize their work towards this.
If they’re trying to solve a problem with the new layout engine and clutter, it really would help to know the objectives they have in mind.
I’m not really criticizing the evolutionary path or the technical decisions made in this document. But I’m really looking forward to know what they’re up to and what they’re trying to accomplish… I hope trey also have an idea too…
I guess you are mixing up GTK+ and Gnome. Yes, the two projects are related but nonetheless different.
Ars Technica have an article (or just speculation?) about the plans for Gnome 3:
http://arstechnica.com/news.ars/post/20080714-gnome-3-0-officially-…
I use GTK primarily in a non-Latin/English environment and these are very important to me:
1. Get rid of stock icons.
2. Get rid of gettext based translations (well probably cannot do away with all of it). Use something like UI XML files that can be translated using Glade or other visual tool (like its done in OS X) and loaded as such.
3. Support a single Object oriented language as a first class platform. Be it C++, C#, java, …. support one of them as a development platform and don’t let it play catchup to the C implementation. I still like to keep C as the underlying library file.
4. better integrated keyboard and input method support. Be able to let users write input methods using text files for complex script input.
1. Get rid of stock icons.
I really don’t understand what this could be useful for. What’s wrong with the stock icons?
2. Get rid of gettext based translations (well probably cannot do away with all of it). Use something like UI XML files that can be translated using Glade or other visual tool (like its done in OS X) and loaded as such.
You are mistaken on this one. Nothing in gettext’s design prevents you to use GUI tools for the translation. You can use programs like gTranslator or KBabel for this.
2. Get rid of gettext based translations (well probably cannot do away with all of it). Use something like UI XML files that can be translated using Glade or other visual tool (like its done in OS X) and loaded as such.
You are mistaken on this one. Nothing in gettext’s design prevents you to use GUI tools for the translation. You can use programs like gTranslator or KBabel for this.
The problem is contextual translation. Gtranslator, etc. tell you what to translate. You fire up the application and find out the translation is in appropriate for the context.
Wow, I think I disagree on pretty much every point!
I can’t see why you would possibly want to do this. In fact, I’d like to see many more stock icons for increased consistency between apps. I suspect what you actually mean is “get rid of icons from buttons”, but you can already do this…
I don’t think there’s any reason that a gettext translation editor couldn’t be be integrated into Glade. In fact, it’s an excellent idea. GSoC next year, anyone?
To me, one of the great strengths of GTK is the fact that you can write apps using pretty much any language you like. Compare this with Mac OS, where the choice these days is Objective C or nothing, or Windows where MS are doing their best to force you onto .NET.
I will agree though that having C as the “default” is not ideal, which is why I’m really excited about the prospect of Vala as a “native” GLib language.
I’m not an international user, so I’ll take your word for it that these things need to be improved
To me, one of the great strengths of GTK is the fact that you can write apps using pretty much any language you like. Compare this with Mac OS, where the choice these days is Objective C or nothing, or Windows where MS are doing their best to force you onto .NET.
If so you should like .Net more
.net is not just a language (c#), but a framework providing language interoperability and cross-language class / method invocation via a common ( for languages whose compiler and/or runtime is ported to the IL – quite some of them, actually http://www.dotnetpowered.com/languages.aspx ) object model and runtime – whereas other platforms require bindings for each desired library, for each desired language
Pictures are worth a thousand words … so what do the pictures mean?
The past shows a photo of a ruin.
The present shows a beautiful mosque.
The future shows a bunch of star ships going into a black hole or an explosion.
So, where are we headed????
“The future shows a bunch of star ships going into a black hole or an explosion. ”
No, those are ships flying through the hyperspace. It’s an image from Stargate Atlantis.(which is btw. my favorite tv series)
That would be a pair of Wraith cruisers travelling through hyper space (cf. Stargate Atlantis).
The presentation was good, but it was interesting to see that there was no agreement on the “canvas” side of things (or even if a canvas was needed!).
That’s a bit of a surprise – I can understand debate being lengthy on which programming language to use (going into Gtk 3), but I would have thought getting a canvas agreed on wouldn’t take all that long…
Maybe the experimental approach that led to Git could be good. In Git’s case, it was a new SCM that was needed, so Linus tried a few things out and came up with the awesome (imo) Git. A few “canvas experiments” by the Gtk devs could likewise lead to an excellent canvas.
Anyway, best of luck to the Gtk devs! There are some good ideas in the Gtk area, one of which is Vala. If that kind of creativity can be maintained, things look promising for Gtk 3.0.
Edited 2008-07-15 00:48 UTC
Actually, there are quite a few canvas experiments in the GTK+ community; the problem is, that they can’t decide now on which one to pick in the end.
Clutter seems to be the most popular (having seen a few stories on it and applications using it) but there are others: http://live.gnome.org/ProjectRidley/CanvasOverview/Canvases