Submitted by “On the 2008 GTK+ Hackfest in Berlin, Imendio’s GTK+ hackers presented their vision 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 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.”
As someone who has never created a GUI in anything other than Java and VB, I am torn between learning GTK+ / wxWidgets, and QT.
QT looks attractive because it has more stuff like XML, collections, networking, threading etc. That is also what makes it unattractive for using QT with languages like Java or Python which already have all that stuff.
Using GTK+ looks attractive because it seems like it is just a GUI toolkit and you can use what libraries you want for the other stuff. But then you can get yourself into trouble if a library you choose isn’t supported on all the platforms you’re interested in or it may get a little hacky using cygwin / mingw on Windows etc.
Right now I’m learning Python by reading a book just on Python. I’m already writing command line scripts, doing DB stuff etc. Next I plan to survey both GTK+ and QT and make a decision where to devote my brain.
Hopefully how nice QT or GTK+ are to work with in Python reflect how nice they are to work with in C, C++ too.
While GTK+ is “just a GUI toolkit”, there are a number of other G* libraries (and best of breed stuff like libxml) that address your concerns, since they’re based on the same cross-platfrom mase libraries as GTK+. If you don’t feel like getting your hands dirty with C, Vala is a great meta-compiler for GObject (and GObject derived libaries) that has a C#-like syntax.
I would encourage you to learn both GTK+ and QT, however. The relative pros and cons of each will better inform your development decisions in the future. Python is a great way to experiment with both, since it has a relatively low barrier to entry.
Hi Funky,
well Qt is available in two licenses: GPL and commercial license. If you don’t like to open your code or pay for a license Qt is no alternative, then you should use Gtk.
If you are also willing to buy a license or GPL is ok for you, then Qt and Gtk are both ok.
If you plan to write applications for windows too I would prefer Qt. Why? Because imho it feels faster and it looks much better under windows than Gtk does.
Just my 2 cents.
Mike
Seconded. GTK on Windows is ugly.
My experience is that it depends on the theme you choose quite a bit.
With Qt you are not limited to GPL though. You can use many of the other popular free software licenses.
http://trolltech.com/products/qt/gplexception
I have used decent looking GTK+ apps on Windows. These include GIMP, Inkscape, and Audacity (well, thats wx but wx uses gtk). I don’t think I have ever used a QT app on Windows except the demo ones that come with QT. Those were fast but they also did next to nothing.
GIMP and Inkscape are GTK, and they look decent, but they don’t look native. Lots of controls behave differently (combo box is one) and the file dialog is not the native one. I could not give a UI like that to a paying customer.
Audacity is native because it uses wxWidgets. But wxWidgets does not use GTK when running on Windows. It uses the native Windows controls, so it looks fine.
Google earth?
Qt is used on Windows quite often. But applications looks native so you couldn’t suspect it is Qt. I discovered some apps really accidentally looking for docs in some packages and finding Qt*.dll . My latest favorite discovered in that way is FotoStation.
Generally it is used is small/medium shops producing highly specialized software with eye on portability (usually Win, Mac, Linux is under radar).
I have not yet used Qt very much. However, from my research:
1) Gtk does things a lot like Microsoft when it comes to messaging. If you know how to create a GUI in Visual C/C++, then Gtk will seem native – you declare your message maps the same way.
2) WxWidgets/WxWindows is need. It does it both the Gtk/Microsoft way, and the Qt Slot way.
3) Qt does not use the Message Map structure really at all – or if it does, it’s all hidden. Rather, it uses something called “Slots”, which are very dynamic and you call at run time to be added to.
Qt is also its own environment that you can easily extend – this is what KDE does for their ecosystem. You also need to get familiar with the QMake preprocessor that puts a lot of the Qt stuff together for you. The downside of Qt is that you have a big check per developer if you are doing something commercial, something that is not open source. (About $4k/developer for most all platforms Qt supports.) So it can be expensive. Of course, if you are only doing open source, then there is no difference. 😉
WxWidgets is public domain last I looked. So you can pretty much use it anywhere.
Gtk is of course, GPL or LGPL.
Otherwise, most things are equal and its a matter of preference.
I thought that wxWidgets used GTK+.
But since GTK+ is LGPL that means that wxWidgets isn’t forced to be GPL.
My guess (based on the wxWidgets websites) is that they treat Gtk just like any other system (e.g. Win32, WinCE, etc.). So their programs inter-operate well.
In order to use Gtk with wxWidgets though, you will need to have wxGtk (wxWidgets for Gtk) installed though.
So where with KDE/Qt you can use a lot of Qt easily (not extra bindings required), you cannot use Gtk easily with wxWidgets without installing an additional binding.
wxWidgets is really its own system – it just relies on underlying OS features/tools/libraries to function with that system (see their flash presentation), which it wraps to provide the functionality. So, while I’m not an authoritative source on this – this is just what I’ve seen from their website, I’d say that wxWidgets is more based on Gtk than Java is.
I would recommend Qt. wxWigets is cool and all, but quite slow. GTK is good, but Qt is well documented, easy to use, and seems to be progressing the quickest.
Personally, I learned wx first, GTK second, and Qt last. Looking back, I wish I had done it the other way around.
What follows is my personal opinion based on my experience writing gui code in python. Others may disagree.
WxPython is the easiest toolkit of the three to get up and running with. It is reasonably extensible, quite pythonic, well supported and an all round good choice
PyQt feels more powerful than WxPython for doing complex guis. It also has by far the best graphical gui design tool going, if you prefer do your guis that way. The Qt license can be a problem though if you’re not writing Open Source software.
PyGTK is my least favorite (and also the one I have least experience with), but still not a bad toolkit. It’s not as easy to get a hang of as WxPython and not as powerful as PyQt. It also has the weakest Windows support of the three.
Anyway, that’s my opinion.
Well I’ll give you my biased viewpoint.
Choose Qt unless you are writing closed source software and have a budget of zero (in which case you should prepare to fail anyway).
I’ve tried both (not with Python though) and for just getting stuff done in a cross-platform way, Qt is miles ahead. You say GTK gives you more choice for what libraries to use, but that’s not really true. If you don’t like the QtXML/SQL/Whatever libs, then you can use any other library you want. But realistically, most of the time you’ll opt for the Qt libs because they are all very cross platform, completely documented, and stable.
For every extra lib you use, you gain build environment hassle, cross-platform hassle, and quality hassle. With Qt, it’s dead easy to set up a development environment, because for most projects you just need the one set of libs, which are packaged together and tested together.
Even if you only intend to target Linux for now, using Qt gives you (or other devs) more options for a seamless cross-platform experience in the future.
My second choice after Qt would be wxWidgets. It has a more permissive license, and is even more native on Windows than Qt (since it actually uses MFC/Winapi controls).
However be prepared for a less well-tested toolkit and some more issues with getting cross platform support right. Last time I tried it, I found a couple bugs in the toolkit just in the first few hours of using it (they were addressed promptly by the devs though).
The vlc devs recently decided to switch from wxWidgets to Qt4 because of the problems they were having with wx. It also doesn’t have the advanced features like a proper canvas and things like Webkit integration (coming in Qt 4.4) and I don’t like the coding style as much. But overall it’s not a bad choice if you need the license.
Edited 2008-03-12 21:22 UTC
does this mean gtk apps wont consume 100% cpu for 30 minutes if i accidentally open my maildir in the file selector?
Let’s hope so. But I do fear that the developers will take your wish too literally. It won’t take 30 minutes, it will take 50.
It’s sad, but Gtk is so slow it’s just unbelievable. Let’s hope reworking the theme system fixes some of it, because I like most of Gtk apart from that.
And the list views… They need to be structured in a better and faster way.
Edited 2008-03-12 19:40 UTC
So basically this means GTK will be catching up to Qt. Canvases, OS-independent communication… these are the things Qt already has.
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).
I am new to Linux GUI APIs, so the following may sound lame:
1. How does SWT compare with GTK or QT? Is it built on top of either of those?
2. What about network remoting support? I have heard of Bonobo/D-Bus, but don’t know if a GUI app running on one machine could access another service app on another machine using built-in remoting support easily in the same API framework (reduced learning curve).
Not lame at all.
SWT is a GUI toolkit for Java. As far as I am aware, it cannot be easily used from other languages, so it hasn’t been brought up here. Certainly if you are using Java it is a reasonable choice.
SWT is like wxWidgets in the sense that it uses the native widget toolkit of the platform it is running on to render most of its widgets. On Linux, since there is really no native toolkit (except perhaps Motif, which SWT can also use), SWT uses GTK. I’m not positive, but I have heard that they cannot use Qt because of license incompatibilities (Qt is under the GPL or a commercial license while GTK is under the LGPL).
Well this is a little bit out of my area, but I think d-bus is for interprocess communication on the same machine, while Bonobo is deprecated. Not sure what exactly would be used for remoting in Qt or GTK (SOAP?). Perhaps someone else is more knowledgeable here.
The GPL and the Eclipse Public License (EPL, SWT’s license) are incompatible. However, in a recent update to Trolltech’s GPL Exception list, they added the EPL, making a Qt based SWT a legal possibility (which I hope will be implemented someday).
http://trolltech.com/products/qt/gplexception
Will it still be in C? If so why why why? OOP is very nice for GUIs. I mean I honestly don’t really care because I am KDE user and not C++ programmer either.
If it’s just that they didn’t like C++ they could have found some other compiled OOP language. To go on a tangent I think what the OSS world needs is a OOP language that is statically typed and compiled that is not C++. I mean considering all the security risks with C/C++ it makes no sense to use them when just getting 95% of that performance will do.</rant>
Will it still be in C? If so why why why?
It’s C because it allows you to create bindings for almost any programming language whatsoever to GTK+. That’s one of the big features of GTK+: to have bindings in almost all imaginable languages.
I mean considering all the security risks with C/C++ it makes no sense to use them when just getting 95% of that performance will do.
Umm, what “security risks” are you talking about?
Might be referring to the common mistakes that newer C programmers make such as allowing buffer over/underflows.
It is quite disingenuous to call this a mistake only “newer”, in other words unexperienced, C programmers make. In fact, you see it all over the board, because it is NOT easy to avoid. C also offers many other opportunities to do the proverbial foot shooting. But I digress.
I don’t know if you’re aware of that, Captain, but you can program Gtk+ Applications in a whole lot of languages.
You can check them here: http://www.gtk.org/language-bindings.html
As you can see, we have a lot of “Supported” languages, and many more partially supported implementations
Cool. Although really from that massive list the up to date bindings are C++, Java, Perl, Python, C#, and Ruby. That’s still better than Qt, but it’s not that much different. Trolltech supports C++ and Java officially, and there are complete bindings for Python and Ruby, as well as for C# (although I don’t know the extent of support there). There are also actively developed Perl bindings but it doesn’t look like they’re ready yet.
Statically typed and compiled and not C++?
Seems like you are longing for something like the Boo language. It is Python with the above characteristics.
Just to add my favourite: Scala (Very advanced type system, runs on the JVM, can be mixed with Java very easily, allows for booth OOP and FP styles in an interesting mix of objects and higher order functions)
Most of the security risks in C (mostly string handling functions such as gets) were solved by throwing out huge deprecation warnings and using safe variants. (fgets in this case)
– Gilboa
It looks like some fantastic improvements are coming to Gtk+ 3.0.
However, if you are looking at using Qt…some people have mentioned the licensing of Qt as a reason you may not want to use it. I disagree – let me explain.
So you want to write a program.
If you’re ok with open source, then the GPL will likely not be an issue and therefore Qt is fine to use.
If you’re NOT wanting to make it open source, then the reason is more than likely that you want to sell the program, and therefore the cost of a Qt license can be factored into it. If your program is not going to bring in say $1500 profit (per OS it runs on) then ask yourself if its even worth the time and effort to write it. Basically, for any small development team that will be creating commercial software, the Qt license is hardly an issue if the software created is of any real worth.
The only exceptions I can think of is if you want to code open source but want to use a different license other than the GPL.
If you’re not going to be distributing your program then the GPL will be fine – you only need to make the code available if you distribute the binary.
That said, Qt is not the best library for all people nor for all situations. Just wanted to share how I feel about the licensing thing thats all
Just to add, Tt does offer a reduced fee for the Qt license for smaller shops.
Actually, Qt now supports virtually every popular OSS license, besides the GPL. The only real restriction is on closed/proprietary usage, and that boils down to a cost-benefit analysis. If actual developers (and not the armchair quarterbacks who post on web forums) find value in the advantages Qt offers for development, then the cost is negligible. But Gtk and many other toolkits still exist as alternatives, which is an important thing.
Just my 2c…
Or you could be writing in house code for a company, research institute or government agency. That’s what I and many people I know do.
I looked into that. The GPL FAQ at gnu says that it is not “distribution” to use your code in-house. This means that you are not required to GPL your code. But then it did say something about an offsite contractor running your code is distribution and if they asked, you’d be required to give them the source code.
Exactly. In-house is not clearly defined enough. Is it still in-house if I give the code to someone at an offsite department? Is it in-house if I give it to someone who works for a different company that is owned by this company. What if two different, unconnected, groups or companies are co-operating on the same project. Can the code be passed between the two and still be considered in-house? What if we send someone a demo under NDA of what we’re currently working on? We also use offsite contractors for several projects (I’m in fact a contractor as well, but do all my work on site).
Far easier to avoid the whole problem. If we’re not 100% sure at the start of the project that we’re going to GPL it, then we don’t use GPLd libraries.
There’s nothing to define. The GPL is very clear. Anyone that gets your software has the right to request the source.
That person has the right to request the code from you.
That person also has the right to request the code from you.
Then everyone that gets the binaries has the right to get the code as well.
If they get the binaries, they get the code. If you’re just demoing the application on your machine, then you’re not obligated to anything.
Then those contractors should get the source if they request it.
The GPL is pretty simple. Those who get the binaries also can request the code. You don’t have to think about the definitions of in-house or anything.
My approach for previous projects was to just include a note in the install dir about the license and an email address where people can request the source. So far I’ve never received a request, despite the software being used by thousands of people. Most people don’t care, and the risk of some computer savy person getting the code and then screwing me is insanely remote that I’m happy with it.
Since then I’ve bought a commercial version for my current project, as it will be much higher profile, but it is certainly possible to use the GPL with little issue for custom in-house software.
It really depends upon what dagw means by “give”. If Spacely Sprockets develops and deploys a point of sale app, the cashiers are not entitled to the source code. But if one of the cashiers copies it off of her register and takes it home, is that distribution or copyright violation? And then she changes jobs and gives it to her new employer at Cogswell Cogs? What is the status of that?
It’s not quite as neat and tidy as you are presenting it.
And then what? If Bob and I are working on an app that links to a GPLd library, but is only intended for use in our department, can Bob still take the code, add some personal patches to it and put it up on his home ftp server and spread it to the world? What if Bob wasn’t a developer, but just worked in my department and I installed the software on his computer, would he still be allowed to do the above?
It’s not so much about getting the source (as it would make sense for the developers woking on the project to have the source) as what happens after that. Bottom line to me is don’t try to use the in-house clause to try to get around the GPL, it just seems too legaly unsure.
I seriously doubt the people I work for would be equally happy taking that risk in all cases. It really depends on the project and the people you work with.
According to the GPL, yes. Of course your company might still fire him for violating their terms of employment (which almost certainly will prohibit this).
There is no distinction between developers and non-developers.
Not to me. But it really depends on the project. For a sensitive project I would use the proprietary license as well.
The GPL governs distribution. You are hardly distributing if you give it to yourself.
Depends who “yourself” is. Are we talking company or individual. Can the individual developer take the code home add some patches and put it up on his private ftp server and spread it to the world under GPL.
Trying to use the in-house clause to get around the whole GPL just seems far too risky.
Both. A company distributing an application to itself is not distribution in the eyes of the GPL.
No, because it is the company that is the copyright holder of the code and it is not up to an employee who the code gets distributed to. There are also countless other restrictions that have nothing to do with software licenses that restrict an employee from doing that – breach of contract, NDAs, confidentiality agreements etc. that are far more important than the license.
You’re creating hypothetical scenarios where none exist. Countless internal software applications have no license at all.
I am positively thrilled by this GTK+ hackfest. GTK+ has had a hard time getting the developer attention it needs, for quite some time. With the recent explosion of new canvas libraries around GTK+(Pigment, Clutter, Hippocanvas etc.) I had been worried that the periphery of GTK+ and possible future directions of GTK+ were getting lots of interest but that this would mean that GTK+ proper would languish from a lack of direct involvement. Fortunately now this no longer seems to be the case.
Right now the larger GNOME community is rallying around GTK+-which is simply great news-no other factor will impact the future of GNOME more than the work done on GTK+. Taking GTK+ to the next level means tackling hardware acceleration of graphics. This means Opengl. Each of the new canvas technologies being developed are trully focused on using opengl to really take advantage of our graphics hardware. This has only become possible due to Intel and ATI gradually opening up the documentation for 3D rendering.
For years the Xorg/Xfree86 communities as a whole were hampered by proprietary hardware acceleration. Xorg is still not directly tackling the 3D end of hardware acceleration-there are still lots of questions about how to adapt X to opengl and opengl to X to make a suitable solution for a 3D hardware accelerated desktop. OpenglES (IIRC) is one solution being explored right now. Slowly Xorg is getting extensions to Opengl pushed in and actually getting ATI/Intel/Nvidia to implement them. This is why AIGLX and composite have become the reality, albeit still alpha quality, that it has become.
Xorg has always proven itself very slow to adopt “policy” decisions. Xorg must run on so many different platforms and different hardware configurations-a blessing and a curse at the same time. But this is changing now. The new driver techs being developed by Xorg and the companies directly working in this field (Trolltech, SGI, Intel) have developed a bunch of strategies to implement hardware acceleration for 2D(EXA) and to smooth the transition to full 3D acceleration (TTM, Glucose, Gladium).
The developments of the periphery of GTK+ are basically leapfrogging a lot of the current design work around Xorg. QT4 is also doing this, by directly tying itself to the hardware accelerated EXA primitives and it’s own opengl pipeline. The decisions about the future of GTK+ play a role in driving the development of 3D hardware acceleration in Xorg- much like GTK+ utilizing RENDER drove Xorg EXA work, and then Cairo being totally RENDER based which magnified the necessity for driver RENDER support. In short XAA, the old Xorg acceleration architecture was ill suited for RENDER acceleration, EXA radically simplified the driver architecture exposing a tiny subset of things to be accelerated vs. XAA but which made full RENDER acceleration possible/plausible.
If GTK+, in moving to 3.0, takes the best from the techs currently being developed on the periphery, then GTK+ will start to gain a lot of really promising capabilities (scene-graph basis, powerful canvas tech, much enhance theming abilities etc.) and this in turn will further drive Xorg into realizing the developments which are ongoing.
Regardless of how these developments play out I seriously hope that the GTK+ folks look over their shoulders at what Enlightenment is doing. Evas provides that which GTK+ wants for the future-without all of the fundamental changes in Xorg and without the dependency on modern 3D hardware in newer GPUS. It is ironic that GTK+ is being left behind by EVAS on the OpenMoko platform-which is producing the graphics of tomorrow on hardware from yesterday(ie graphics hardware lacking powerful 3D acceleration.
Glitz as a opengl backend for Cairo looked promising, but alas it was not meant to be. Glitz needed Nvidia 8XXX tech to be able to do what want to see. Luckily others are working in this area-and what Glitz has promised will be delivered by techs not as demanding and thus more realizable. Once the Cairo–opengl bridge is fully built, all GTK+ applications and apps like Firefox3 and OpenOffice 2.4 will start having some serious hardware acceleration at their disposal.
Things are looking good.
**update**
Carl Worth sheds some light on XAA, EXA and TTM:
http://cworth.org/talks/lca_2008
phew..good to know that my explanations are not entirely crack-inspired
Edited 2008-03-13 11:36 UTC
All these ideas for GTK3 are nice, but to the public, development of the current GTK2 appears to be of glacial proportions.
The promises are nice, but can we expect anything practical on the mid term?