I think GTK+ shows how an open-source community can paint itself into a corner by becoming "too big to fail".
Gtk+ 1.0 was released in in 1998. Here's a list of vastly superior UI toolkits that were developed from scratch before Gtk+ 3.0 release:
* Microsoft's WPF (first release in 2006)
* Android's Java-based UI framework
* Palm's webOS UI framework
* Cocoa in Mac OS X (first release in 2001 - and before you nitpick, I know it was based on earlier tech from NeXT)
* iPhone UI (granted, based on Mac OS X UI but a lot of it was new)
The technology behind Gtk+ (C, even when written in a disciplined, object-oriented fashion) makes it painful to program against. It was fine when the alternative was Win32 but the above mentioned toolkits use higher-level languages (java, c#, javascript, objective-c) making them not only easier to program against but also easier to improve the toolkits themselves.
I don't follow Gnome development but my outsider perspective is that Gtk+ is a huge technical debt and there are no signs that the community is planning to ditch it for something that can go head-to-head with those other technologies (mono is the only initiative trying to move the state of the art of implementation technologies on unix but it doesn't have UI component (other than silverlight implementation, which is WPF-lite)).
How do you use WPF from java or cpython? How do you use the webOS ui from haskell? How do you use the Android UI from ocaml?
Open source core libraries are written against the C ABI (even when employing object models like GObject) so that everyone can bind to them easily. For example:
Gtk is to my knowledge the first toolkit one could make a whole UI with, dynamic resizing and all, dynamically (from XML files loaded at runtime), using a graphical editor (Glade), and all of that since at least 2000 (I know I submitted some patches to it back then). No toolkit today replicates the same ease of development. Gtk has many binding to various languages, and is relatively well-documented.
Why has it not been successful? Well IMO because of several reasons: deep dependency on X, making its use on Windows a kludge at best; hostility in the community to making it viable for commercial use (basically, polishing it enough for integration, and willingness to compromise design purity for integration with native widgets), and the horrendous plague that seems to be the bane of many open source products that focus on Linux: how hard it is to compile, the many dependencies, not providing easy to use complete packages for Windows, ... On Linux it's no issue, you've got all dependencies already and otherwise your distro takes care of it. On Window you need(ed?) to download 5+ various packages with different build systems, somehow integrate them (with different build systems) into your build, and if you wanted to use C++ you needed an extra 3 or 4 (for gtkmm); and then the result was still a second-rate citizen on Windows.
Plus there was the senseless bickering between Gnome and KDE (yes yes, competition is healthy, blah - if I had a penny for every hour wasted on that, I'd retire on the spot), the 'GTK = C' FUD, and the lack of people who wanted to go the extra mile of making a produkt rather than a nice proof of concept. The people familiar with it didn't care to make it easier for others, GUI tools were considered to be for 'pussies' and 'VB programmers' and so the self-righteous dogmatist make himself irrelevant by being surpassed by products who didn't think themselves above the average programmer.
I'm still a bit bitter, at the time I was so much cleaner to write GTK application than moc-infested QT code (yes I know things have changed).
Yes, there are several more UI toolkits, I haven't followed E development for 10 years though. It was the Linux darling in the late 90's, but afaik it was Rasterman working on it mostly on his own, and when alternatives showed up, E (as in, the window manager) became irrelevant. Is it still in modern distro's?
I believe Vala is the language that the Gnome/GTK devs want most programs to be written with in the future. Which is basically how Windows' GUI works: C core API (win32) for backwards-compatibility, with higher-level .NET bindings to them for newly written programs.
I would not call Gtk+ a "huge technical debt", but there is some truth in what you say.
Gtk+ development has been badly under-sponsored by the companies that sponsor GNOME development. In recent years, Cairo and then Clutter were the hot new toolkits that many people used to supplement Gtk. (Clutter provides a 2.5D canvas that can be used in Gtk+ applications and Cairo is used by Gtk+ to draw widgets.)
Qt, on the other hand, is backed by Nokia and has been undergoing constant development. The difference is noticeable.
There was a time when people spoke excitedly about creating new GNOME applications using Clutter, because Gtk+ itself didn't support what they wanted to do. Clutter was (and still is) blessed by GNOME. Among other programs, many GNOME games have been rewritten to use Clutter with a small Gtk+ wrapper.
I am no longer involved in GNOME, so I can't say for sure how people feel right now. I would guess that the attitude is what it has always has been: Gtk+ might not be amazing, but it is good enough for what we need. Use Clutter if you need a canvas. It would be insane to switch to another toolkit, as that would kill the GNOME project.
Edit: I want to add a few points I forgot to mention:
1. Gtk+ 3.0's support for CSS theming will level the playing field with other toolkits, and especially with Qt. This is the most exciting addition to Gtk+ 3.0. To be honest, it is long due.
2. Qt is my personal choice for a cross platform toolkit in high-level languages. Qt Designer, QLayouts, and Qt's language bindings are very good, and have all been present for years. Gtk+ has good language bindings, but it is lacking in all of the other areas. Furthermore, Qt's last few releases bring many new features that Gtk+ is missing and wont implement soon.
3. Despite my preference for Qt, I still use Gtk+ for small small C programs because Qt is written in C++. Gtk+ isn't as fun as Qt, but being forced to use C++ is plain out painful.
The release announcement says that Gtk3 has switched to Cairo to draw the toolkit behind the scenes:
Cairo drawing throughout. GDK no longer wraps the antiquated
X11 drawing API; we've made a clean break and exclusively rely
on cairo for all our drawing needs now.
As for Clutter, the OpenGL based canvas, Gnome-Shell (aka the Gnome 3 desktop UI) uses cluttter throughout. The new window manager is called Mutter which is a fork of Metacity to use Clutter for hardware acceleration and all the panels and other desktop UI are also rendered this way.
Really? There are quite a few Mono apps that use its GTK# bindings. Their inclusion in the default installs of many mainstream distros has been the cause of much contention with the anti-mono/Microsoft crowd.
GTK+ was my first foray into GUI programming when I was a kid, and I still think it's pretty slick. I really liked the concept of boxes and nesting stuff, and how it would figure out how to lay it out. And that it could all be done in code and be understandable! Not some wonky OLE2 / Swing "Form Designer" that I was doomed to never understand.
Actually Swing works pretty much the same way, which is why I liked it. What I couldn't stand was stuff like Qt, which wants to generate / pre-process a lot of code.
I've decided my rule is, I want to either do everything in code (like GTK) or nothing in code (like Cocoa), but none of this "here's a utility that generates code for you" like Windows Forms.
I think they really cleaned this up in the Qt3 -> Qt4 transition - your Qt Designer forms are still turned into code, but not in a generated file that you're supposed to edit. Instead it's a standalone class that you inherit in your own class.
So uic and moc are still there, but they may as well be generating object code - you never have to read the C++ that they spit out.
To me the Qt and Cocoa approaches look the same. Qt is built on top of C++ pretty much the same way Objective-C is built on top of C: there is some syntactic sugar to allow dynamic binding and you do not ever have to look at the intermediate results if you do not want to. You can hack into the details of the implementation if you prefer, and you can do it in both frameworks.
Seems like the changes are more behind the scenes -stuff, rather than developer or user visible stuff. While GTK is not my toolkit of choice, grats for evolving and getting a major version out.
Gtk+ 1.0 was released in in 1998. Here's a list of vastly superior UI toolkits that were developed from scratch before Gtk+ 3.0 release:
* Microsoft's WPF (first release in 2006) * Android's Java-based UI framework * Palm's webOS UI framework * Cocoa in Mac OS X (first release in 2001 - and before you nitpick, I know it was based on earlier tech from NeXT) * iPhone UI (granted, based on Mac OS X UI but a lot of it was new)
The technology behind Gtk+ (C, even when written in a disciplined, object-oriented fashion) makes it painful to program against. It was fine when the alternative was Win32 but the above mentioned toolkits use higher-level languages (java, c#, javascript, objective-c) making them not only easier to program against but also easier to improve the toolkits themselves.
I don't follow Gnome development but my outsider perspective is that Gtk+ is a huge technical debt and there are no signs that the community is planning to ditch it for something that can go head-to-head with those other technologies (mono is the only initiative trying to move the state of the art of implementation technologies on unix but it doesn't have UI component (other than silverlight implementation, which is WPF-lite)).