GTK+ 3.0: Getting serious.
GTK+ has come a long way. From its humble beginnings as “The GIMP ToolKit”, it is now used in a plethora of applications. In fact, GTK+ is very popular. GNOME, one of the leading desktop environment on Unix systems, uses GTK+ almost exclusively. The Gimp is built upon GTK+, of course. And there are many commercial software developers like Adobe, NVidia and VMware that decided to use it as a base for their products.
Still, there are several shortcomings with GTK+. Development of the 2.x series started back in 2002. Since then, GTK+ has ripened and aged. It has aged well, but still: its age shows. Throughout the 2.x cycle, several years now, the developers have kept GTK+ ABI compatible. This keeps application developers depending on GTK+ very happy: they can be sure that code linked to an older version of GTK+ continues to work with newer releases. Packages released back in 2002 will continue to work with new library releases. That’s great, because no third-party application developer likes to rebuild and repackage the whole product line, just because a new version of the underlying libraries got released and all the distribution start packaging that version. It causes work and trouble. And for commercial/proprietary developers that means costs.
The commitment not to break ABI made a lot of people very happy. But it also put very tight constraints on the GTK+ developers. It’s not that easy to add new features and remain ABI compatible. Minor features, yes. But as soon as you want to make radical improvements and need to change the exposed data structures, you run into serious trouble. It just not possible beyond a certain point.
On the 2008 GTK+ Hackfest in Berlin, Imendio’s GTK+ hackers presented their vision [1] of GTK+’s future and the reasons why they think that GTK+ has to make a step forward, embrace change and break ABI compatibility. Other GTK+ developers [2] have also voiced their opinions, listing parts of GTK+ that need serious love, but state that they don’t require breakage.
Whether or not these are the things that will mark the road to GTK+ 3.0, almost all of them need attention. And give hints to the shape of things to come.
Theming:
Theming is one major aspect of GTK+ that needs a serious overhaul. Theming in GTK+ sucks and blows big time. The initial concept of how theming works in GTK+ stems from the very first releases and never received serious love. As a result it is very difficult to do fancy graphic things in GTK+ or to make custom widgets that fit into the rest of the desktop. The funny look of Evolution’s tree headers in some themes is one symptom, but every developer with the need to write custom widgets is looking for a hard time.
There have been several suggestions on how to do that, some of them involving CSS-style theming [3]. CSS would be nice, for sure. But even the ability to paint one widget to mimick another would be a huge gain. Application-specific theming and custom layouts? Delicious.
Animations:
Although it is possible to create animations in plain GTK+, it’s not very easy to do. Out of the desire to create fancy interfaces in the image of the iPhone interface arose several GLib/GTK+ inspired libraries; Clutter, Pigment and Moonlight. All of those have drawbacks, however: Clutter doesn’t use the GLib event system, Moonlight is written in C++ (a no-go for a GTK+ library) and Pigment is in a very rough state. Still, there are very solid plans to what extent a scene-graph library might interact with GTK+ and what requirements such a library has to fulfill [4].
Canvas:
GTK+ has no standard Canvas. There is a GnomeCanvas, but it’s deprecated, not very popular and lacks some key features, like drawing GUI. Many developers resort to plain Cairo when it comes to custom graphics, but Cairo is lacking a way to draw GUI elements also. Nothing gained. There are some possible candidates [5] for a possible GTKCanvas, but none of them seems to be the right candidate. And then there is the question, if a specialised canvas is a good idea at all.
This problem might be solved with the emergence of the aforementioned scene-graph library; instead of introducing a specialised library for custom paint operations, make that library the standard way.
OS integration:
GTK+ is not limited to X11 systems anymore. There are many GTK+ applications that have been ported to Windows and enjoy a surprising popularity there; Inkscape for example has a significant Windows user base. And OS X gets more important with every passing month. Some of these applications make extensive use of operating system features. Up to now, GTK+ featured only a limited set of functions to provide access to operating system functions, but the first solutions addressing this problem are starting to appear [6].
Introspection:
One of the GTK+ buzzwords of the last few month has been introspection. Introspection allows to, well, inspect an object, its methods, public members and its inheritance. This is not only very comfortable for debugging, it also allows for very easy bindings: automated bindings for your favourite programming language? Here it comes. It might still be a while until all parts are in place, but already the results are amazing [7].
It might still be a long time until GTK+ 3.0 gets released. And in any way; GTK+ 3.0 won’t be about adding new features. There are still some mistakes of the past lumbering in GTK+. Exposed private structues, public members that get manipulated directly: things like these have to be fixed before a GTK+ 3.2 can start adding features [8]. But with some of the features, especially a scene-graph, window-independent widget placing and over-rideable paint methods for GTK+ widgets, GTK+ is starting to look very interesting again.
[1] Imendio’s GTK+ 3.0 vision
[2] Gtk+ Hackfest 2008: Day one and a half
[3] GUADEC 5 Notes
[4] New Theme API
[5] Canvas Overview
[6] libgtkhotkey 0.1, Portable Hotkey Integration
[7]
Future of GNOME language bindings
[8] GTK+ 3.0: Enabling incrementalism
Federkiel 
interesting, thx. Could you please link references ?
Clutter doesn’t use the GLib event system,
first of all, there’s no “GLib event system”. there’s a GLib main loop, and Clutter fully uses it to integrate itself with libraries such as GStreamer and GTK+ itself.
actually, Clutter has the same dependencies GTK+ has: GLib, GObject, Pango, GdkPixbuf.
Reading the plan, it seems like a solid, gradual approach that should allow a smooth transition from Gtk 2.x(last) to Gtk 3.0 without source code changes. I like the plan.
I notice that part of the plan is to replace all GObjects with IDL files which create the GObjects (thus allowing Gtk 2.x(last) and Gtk 3.x to share a definition even though they have different definitions).
I haven’t used http://live.gnome.org/Vala, but from the looks of it, it seems to be precisely the sort of tool that can be used to ease the transition as
a might good foundation for the IDL language.
It already produces C-compatible GObjects, is planning to provide full Gtk+ binding, has getters/settings, access controls, and is rich enough to provide
compatibility macros for the bug 2.x to 3.x if it happens.
Of course, the full Vala might be too much for an IDL compiler, it has a few strong things going for it:
1) It already exists, has been debugged, already used to create applications, is actively maintained, and has an active mailing list.
2) It has documentation (important but something that takes ages to be created by programmers who really want to be doing other things)
3) It’s close enough to C/C++/C# to be easily understandable and it’s requirement on being GObject/GObjectIntrospection compatible makes this option a possibility.
4) It’s something that can be pointed to today as a migration path to 3.x. It’ll likely take a few years before all major 2.x apps get ported to 3.x, so getting new apps using the IDL early is extremely important in order to make the 2.x to 3.x painless (at least compared to the horrible 1.x to 2.x migration. Some Gtk 1.x are *still* not migrated).
Hi,
there are many aspects, and I must admit I could write a whole lot from a user’s perspective. There are so many important things to consider.
Hopefully a transition will be rather slow (and smooth) from a Gtk2 to a possible Gtk3.
I would like to emphasis on the CSS aspect though, less on the theming aspect. The point which for me is the most important one. It is actually the one I personally think is the most important one!
=== Look and Feel (and modifying this!)===
I am using ruby-gtk ( ❤ ruby ) a lot and whenever I need to design/layout widgets, I start to curse slighty and look for the shortest route to achieve an acceptable result.
I miss my margin:5px or padding:8px, i miss text-decoration:underline, especially when I struggle with Gtk::Alignment, or use a table layout simply because I dont know of another easy way to arrange what I want to have …
The way with CSS is very intuitive for a human brain once you read it and fiddled with it, and CSS is well known for MANY people – they could o adapt widget sets to their individual needs easily. Need pink with huge borders? Sure enough!
Chrome glossy with fancy colours? Easy.
Personally I would love to see this taken to a much much stronger ground within Gtk3.
But I think a “CSS-style theming” wont be enough.
I really mean a general CSS component based theming, one where the buttons in a web app i wrote would behave similar to how Gtk apps could behave, i.e. padding, margin, colours (which brings me to another point, it would be cool to embed Gtk apps into firefox browser. But I agree, this is a totally different topic..)
The WWW CSS is not the be all, end all solution. I miss variables. I miss component-styled CSS, where I can group CSS statements based on widget sets too, easily (Widget A has these CSS rules, Widget B inherits from it and the user can extend from it)
Also it did not help that CSS3 never really got realized fully… The -moz CSS compoments at times can really be cool! Just not standard….
But please please please please please please please PLEASE no gtk rc_files !
I know what is possible with them to some extend, saw a few widgets like a special border on a button – but I CAN NOT STAND HOW THEY LOOK. 😦
I will never embrace something like:
MyButton::focus-line-width = 3
MyButton::focus-line-pattern = “\10\2”
Yes, denoting a pattern may be nice and it can be useful but it also misses the CSS aspects out!
If i could have a vote I would make it similar to CSS and then use all the extra aspects you would need there, like focus-line-width
(Besides it is IMO not good to tie it to a specific class in Question, such as “MyButton” anyway. CSS like themeing should be component independent in its core set. Introspection is also about making objects more transparent)
Ok, sorry if that sounds confusing, I hope you can make sense of this. Hopefully you guys can put up updates every now and then to the whole process!
Sorry, I forgot one thing 🙂
The way about CSS is also about empowering more users to style the compoments in ways they see fit. i.e. how firefox allows you to override the chrome .css files
Sounds great to me. GTK is a superb toolkit with _excellent_ documentation, but there are a few annoying shortcomings (at least for a developer like me).
A few things I would like to see is re-supporting Win9x (impossible, currently, with cairo), speed/memory improvements (we all know GTK ain’t the least-latent, lowest memory-usage UI API on the block), etc.
Let’s just hope that GTK becomes faster and more lightweight with the 3.0 release, and not the other way around.
GTK+ 3.0? Sounds like Qt =)
Sounds like XUL =)
“Pigment is in a very rough state”
Could you be less vague please?
And OS X gets more important with every passing month. Some of these applications make extensive use of operating system features.
Does that mean compiled GTK apps on OSX will finally use the proper top menu bar?
Hi philn,
pigment has no scene graph and there is no way to embed GTK+ widgets. Both features are planned, though. The interpolation system also lacks some techniques, like splines.
This post is very hoting, and this blog is high ranked in
the top blogs report . You can
earn some money with a good blog like this.
@TejWC, it is up to the applications to handle that but we have made it very simple to do with, you can see our GTK+ Mac OS X integration page for information on how.
Thanks for the write up, I agree that it would be helpful if the links could be turned clickable.
I would love to see decent ARGB/Transparency support for everything.
For instance if you want to make a GTK theme, its impossible to make the back of the Window transparent. Murrine theme engine recently did quite a lot of work in this area, but it still requires applications to be manually patched. It would be nice if it was just supported in GTK.
That is good news. Ability to use any scripting language to make widget would be nice !
All the best !!
A high level language like ruby or python or vala or maybe C++ will be really a good move. Java and mono are no no.
What about multitouch support?
As I understand, Xorg support for multiple inputs is right around the corner, so the next step would be for the toolkits to support it.
Cocoa on Mac OS X is already there with Leopard and CocoaTouch for the iPhone, and as input devices change and the traditional keyboard+mouse fades away, this approach to interaction will give way to drastic improvement in UI design. There’s no reason for GTK+ to lack in this area.
– Simon
@CoolGuy, not sure what you mean exactly but you can already develop your own widgets in scripting languages such as Python and Ruby.
Do you mean writing a widget in a scripting language and use it from a C application. That requires more work but can be done.
On theming: someone could stand to clean up the theme names as well. I once started making a GTK theme, only to discover that the tabs which are not the currently active one are all drawn with ‘active’ style (also used for “the mouse is down on you right now” for buttons). When I realized I’d be dealing with a heaping mass of special-cases, and there was no “theme test demo app” which displayed all the widgets for me to see my work, I quit. Life is too short for that.
Nowadays I’m using the Mist engine with KDE’s color scheme applied. It’s a lot less painful.
[…] GTK+ 3.0: Getting serious. « Federkiel GTK+ 3.0: Getting serious. « Federkiel […]
I would like to see a (WinCE) PocketPC port of GTK.
I would dearly love to be able to drop MFC into the junk-bucket, and deploy a GTK+ user interface on Windows, WinCE, & Linux.
i mean desktop widgets
“Future of GNOME language bindings” sounds like Kross 🙂
It would be nice to be able to rename files and folders in the File Dialogs.
You forgot one very important thing: a memory management system that works. If you have this, then maybe I won’t have to restart X every few days to reclaim all that leaked memory.
Raphael,
Pigment has GTK+ support already, since few months… You can embed any Pigment app in a GTK+ window
@philn, how is the embedding done?
[…] GTK+ 3.0: Getting serious. « Federkiel (tags: linux) […]
philn,
Ups, I didn’t get that one, sorry! 😀 It didn’t see it in the changelog. Do you have some links for more information? Some examples?
Presumably you mean that Moonlight is written in C#.
There’s also that idea that Moonlight is licensed to Novell for 4 years and may not be compatible with GPLv3s patent provisions.
Why not use QT ? It has all you need
[…] bien, la empresa Immedio, especializada en el desarrollo de Software para Gnome, ha propuesto unas ideas de cómo implementar GTK+ 3.0: qué cambiar, qué eliminar, y qué añadir. Como comentan en un informe, GTK 2.x esta en el final […]
I think for GTK3 they need to massively solve the ZILLION of library dependencies that GTK+ needs. Atk, cairo, pango, pangocairo, gtk2x11, libxml2, zlib, pnglib, tifflib, jpeglib… and also to make glade and gtk–(C++) part of them(which adds even more depencies… libglade2, libglademm, gtkmm, pangomm, cairomm, etcccc! )
Cyber posted:
[quote]Why not use QT ? It has all you need[/quote]
Because Qt is not free for commercial or closed-source usage… but GTK+ is.
Oh ye Gods. CSS?
No. Bad. Stop it.
I think it’s time to abandon the sinking ship that is GTK. I think the entire system needs to be rethought (and renamed) and given some serious effort before it will be worth continuining development on. Carrying on the current trash of GTK2 into 3 would be a crying shame.
Isn’t GTK the Gnome Toolkit?? 🙂
@arjun,
No, it began as the GIMP Toolkit
@Mikael,
AFAIK the Pigment’s window is embedded in the gtk+ window via its window id
@Raphael,
https://code.fluendo.com/pigment/trac/browser/trunk/pigment/examples/gtk.c
http://base-art.net/Articles/92/
@philn,
that’s not exactly what I was talking about. I know that you can embedd a Pigment canvas into a GTK+ application, but there is no way to put a GTK+ widget on a arbitrary place on the Pigment canvas and have it painted, at least none that I know of.
Ok I misunderstood you 😉 You’re right, it’s not possible to do that ATM. But it sounds like a feature Pigment should provide. Definitely worth a ticket, IMHO.
[…] In a largely prophesying look, Federkiel looks into possible and developing parts of GTK+ 3.0. GTK 3.0 – Get Serious […]
Oh, no! Please don’t break backwarts compability! GTK 1 is still with us. This should tell you something. People have better things to do than to adapt all their GUI code to another toolkit (or a new version with incompabilities) that is written in C and thus CANNOT make significant progress.
[…] Risorse esterne correlate: Ubuntu Brainstorm: Help to develop Gnome 3 GTK+ 3.0: Getting serious. […]
@Tuemmler
Well, if you take a close look at it, you’ll see that GTK1 isn’t with us anymore. It’s dead in the water. There is not support for antialized fonts, no support for Unicode, the last version has been released back in 2002. So, honestly; GTK1 is as dead as you can get.
Also; backwards compatibility is broken on the ABI layer. You as a programmer shouldn’t bother about breaks in the ABI layer as long as the API stays the same. And since one of the goals of the ABI break is to ensure that futher API breaks may be kept on a minimal level, you should be quite happy about it.
Last, but not least; if you think that the fact that GTK+ is written in C, why do you care at all? If you don’t think that GTK+ has a future, why don’t you take a look at QT? It written in C++ and it’s rather nice.
As a side note: Since all common programming languages, like C, C++, Java, C#, Python and so on are Turing-complete, everything expressed in one language may be expressed in another. The statement that GTK+ cannot make “significant progress” because it is written in C is quite silly.
Raphael the comment that all languages are Turing complete is quite unfortunate 🙂 . This apart from obvious means pretty much nothing when coding. You can do the same library using prolog since it is Turing complete, but it might be rather hard. With respect to newer languages, I also prefer C++, than Cobol. Don’t take me wrong: Original comment was not better so everything might be simply a misunderstanding.
Hello Roger,
well, I as well try to avoid having to code in Cobol; I did it once and never want to have to do it ever again.
It is also true that, although one could even write GUI programs in XSLT since it is Touring complete, it would be a waste of time; to complex, not suited for the task.
However; I fail to see why the use of C should keep GTK+ from making “significant” (whatever significant is) progress; C is an excellent language, used in every possible application one can imagine. Sometimes C is cumbersome, but every language has its own problems. I for one don’t really like C++. To me it feels like an incoherent mess, made out of four different languages (C, Object-oriented features of C++, pre-compiler statements, standard template library), hold together by a roll of duct tape. I’m not sure that the use of C++ would be a boon to GTK+.
There are other, more promising efforts to bring object orientation to GTK+; Vala. It’s a fantastic language, simple, elegant and clean. And while it compiles to plain C code in the end (and is thus binary compatible to C), it brings along such many nice features, found in modern programming languages like Pyhon, Java and C#.
Take a look at it at http://www.vala-project.org!
The GTK API cannot make progress in C because C’s memory management sucks (no GC). Since I develop my applications in FreePascal (yeah, no GC either, I know), binary compability is quite important to me.
@Tuemmler,
yes, C doesn’t have a Garbage Collector, but neither does C++. There are GCs to use with C++ (like the Boehm Garbage Collector) but those can be used with C as well.
If the use of a Garbage Collector your only issue with C, I urge you to look at Vala (http://www.vala-project.org); while it doesn’t provide a Garbage Collector for C, it vastly simplifies memory management (managed memory, they call it), provides a simple, clean and elegant programming environment with all the features you’d expect from a modern programming language, while maintaining binary compatibility to C.
To the c++ advocates if you want to use c++ then choose a language designed for c++ (fltk, fox, gtkmm, qt) but leave gtk+ alone and stop trying to
push c++ down our throats! Gtk+ is a c programmers toolkit and we want to keep it that way.
@caracal; I’m sure you meant to write : “… then choose a toolkit designed for c++”, didn’t you? 😉
Sorry i was caught up in the moment and made a mistake what i meant was “then choose a toolkit designed for c++” 🙂
What about Apache2 license ? It would be lovely to have Apache2 license GUI toolkit
LGPL is allowed in commercial use but thare are many to prefer Apache2 license.
I believe that it would spread GTK even more.
I think it’s a good idea to change over to an OOP like C++. The object oriented way is better for the human brain. You have tools like UML to visualize your architecture, to discuss it with other guys, to think about details.
GTK is *already* OO in C, and it’s written in C for a reason. *Anything* can talk to C easily, the same can’t be said for C++.
Too bad GTK+ will never become as good as Qt4. GTK+ needs to drop the ugly C interface. C isn’t meant for GUI work. Look at how win32 is. C is meant for other things. Hence why game developers aren’t using C anymore. Because C++ has inheritance, operating overloading, ploymorphism. What does C offer nothing really. Maybe speed to a certain degree. But give it up, either fully going C# or go C++. Because you’re losing the race one way or another sticking with C.
The only thing I care about in GTK+ 3 is RGBA support. I find it to be pretty good in its application in GTK+ 2.
Sure, Murrine (A GTK+ 2 engine) has some RGBA features, but it only supports maybe a handful of apps… and they have to be precompiled for it or use a plugin. Not good.
So yes, a delivery date on RGBA support would make me very happy, as well as some themes that would use it.
[…] abgerufen am 14. Juli 2009↑ blogs.gnome.org the future of …, abgerufen am 14. Juli 2009↑ Federkiel – GTK 3.0: Getting Serious, abgerufen am 14. Juli 2009↑ GNOME: Get Footware (englisch) – Liste mit Distributionen mit […]
Nice article, thank you..
[…] desktop shell. Promised to be the pinnacle of the much talked about GNOME 3.0 release (which was happening and then not happening and then happening again) that is currently scheduled for September of 2010 […]
With Nokia purchasing Trolltech and from Qt 4.5 on changing to the LGPL License and QtCreator getting better with every release, I don’t see the need for GTK any more. All the problems discussed here are not an issue in QT. I am only starting to learn QT/C++ at the moment and I have to say I find it much easier to understand and fare more elegant than GTK+.
But then again I am just a newbie when it comes to GUI development.
Hello Justin,
is there a ‘need’ for GTK+? Is there a ‘need’ for Qt? I don’t know. 😀 Both toolkits have their uses and both are (in my opinion) equaly usefull.
GTK+’s usefulness is in its easy portability and bind-ability. Especially with the recent progress to GObject introspection, it gets easier to use GObject (GTK+ is based upon GObject) code in all kinds of scripting languages. Gnome-shell (aka: next generation Gnome desktop) makes heavy use of GObject introspection and almost all ‘glue’ code is written in JavaScript. (I recently extended the gnome-shell calendar with calendar weeks, took about 10 lines of code)
My personal problem with Qt is its close relation to C++. While I tend to like C, I lead a personal vendetta against C++, that bastard language from hell. If you like C++, I guess Qt isn’t so bad. But I see Vala as a better solution. If you are new to programming and GUI development, I encourage you to take a look at Vala. It’s a nice, clean language, inspired by C#, has memory management, for-each loops, collections, generics and all kind of nice features. And it generates GObject code, so you’ll be able to use all Vala-coded objects in Python, Ruby, Javascript, et al. immediately.
I do agree with you, by the way; Qt keeps getting better. 😉
Hi Raphael
I fully understand preferring some languages over others and hating other languages, but Qt has many bindings for other languages if you like things like Python, if that makes a difference, and is cross-platform and portable. I have recently heard the name Vala a few times. Maybe if I get time I should check it out, but at the moment learning the fundamentals and concepts is my focus.
I know and admit I don’t know the full store from both sides of the fence but the most compelling things I like about Qt is the event system using slots and signals and the layout framework. I just find the amount of code required to do something complex is worlds apart from other platforms I looked at. The most recent addition to Qt that I also really like is QtCreator.
I suppose my bias also stems from my love for KDE4 (>=4.3) and I am really not 100% sure about this Gnome Shell that is in development. In the end, unfortunately software development is often an emotional choice and I find emotions often get in the way of making the correct choice and often prevent progress, through open source into the pot and things can even get more distorted.
I will try to keep an open mind about GTK+ going forward, but I have to say that I am already sold on Qt. The pass of the progress and Nokia’s new found openness makes me feel very comfortable about Qt’s future.
REF:
http://en.wikipedia.org/wiki/Qt_(toolkit)#Bindings
Hi,
First of all, IMO both toolkits are great!
* For the visual designer, I miss in Glade the functionality of putting the widgets anywhere (by simple dndn) and them telling the designer to “discover” the layout containers(Qt Creator does this jobs quite well!).
* AFAIK, the CSS features in GTK+ 3 are already present in the latest releases of Qt (to confirm!)
* I’ve never seen an example where Qt’s “slots” and “signals” couldn’t be replaced by Gtk+ “events” and “callbacks”. If a signal has many slots, for example, it’s enough to make the callback (event handler) notify whatever he wants… Isn’t the “slots and signals” mechanism only an implementation of the Observer design pattern? Anyway, this is Qt not C++ (unless you use libboost).
* For the languages, I’d like to mention that, in my opinion, include files is an old way of helping compilers do their work! Having .h and .c(pp) is boring (yeah, I know IDEs manages well the source pairs, but anyway…). Have you ever looked a .h or even .c(pp) file with lots of preprocessor directives #macro, #ifndef, #ifdef __$$UGLY_VAR_NAME$$@*#__, etc?
And complex Makefiles? And m4 macros, shell scripts with lots of sed commands with lots of magic regular expressions (don’t get me wrong, I like regex! Usually they’re very useful!)…
One thing we have learned: readability counts!
Now going back to GTK+ :: I like Vala! And I like even more her sister: Genie.
Genie : python-inspired syntax
Genie and Vala: type inference, compiled to native code (ok, it pass through C firstly), NO INCLUDE FILES, good OOP support, EXTREMELY EASY INTEGRATION WITH EXISTING C LIBRARIES THROUGH .vapi FILES.
The problems: not enough documentation, it lacks credibility (maybe because people haven’t tried them yet)..
I go with Gtk+3 + Genie.
I hope this comment don’t start yet another war here…