Alex Hudson

Thoughts on Technology, Product, & Strategy

Qt and the LGPL

Someone asked me my opinion on the licensing of Qt a couple of days ago; not that my opinion is worth that much but this is a relatively interesting change. On the face of it, moving to LGPL isn’t a major difference – obviously, it enables proprietary software to use the library without paying a commercial license, but the market for third-party applications on GNU/Linux is pretty slim. The relaxing/opening of the development process is much more important, assuming that it actually happens, although I imagine that won’t sink in for a little while yet either.

What this does remind me of, though, is a blog post from the middle of last year. It took me a little while to find it again, but I think it’s worth quoting a little bit of it. The subject of the post is “Flames Welcome (Is a Qt GNOME desirable?)“:

“Is this going to happen?

“First off this is a highly unlikely scenario. The planets would have to align, Qt would have to go LGPL, Nokia would have to loosen controls on contributions to avoid a fork, the Qt team would have to accept a community which has slightly different goals and the GTK+ team would have to signal their willingness to move.”

So, what I think is interesting here is that this alignment of the planets seems to have half-happened: Qt has changed its license, and supposedly it will be easier to contribute. While the original idea had some roadblocks in the way, it does seem now that there is nothing preventing this scenario.

The rest of the blog post is well worth reading: it outlines some of the many advantages in moving to Qt. The main thing, for me, is that Qt is a relatively complete toolkit with a reasonable design – it’s not perfect by any means, but a lot of what people want Gtk+ to do is already being done in Qt today. I suspect the effort needed to catch Qt up to Gtk+ in those areas it isn’t as hot would be comparable or less than getting to Gtk+ 3. And while the ISVs currently using Gtk+ would be expected to switch, Gtk+ seems to be an API break anyway.

Of course there are plenty of downsides – it would be a huge effort for not much immediate gain. However, I don’t think the decision would be usefully made on looking for immediate gain – it would need to be a longer term play in any event. Which leads me on to my second point:

In these days, it does seem very bizarre that application designers are so thoroughly tied to widget toolkit. Clearly, when you need to write custom widgets then you’re locked in, but it’s a bit odd that many apps create their UI from code rather than from some kind of designed file. Perhaps the switch shouldn’t be to a new toolkit, but a more standard way of describing UI. Qt Designer has a format, MonoDevelop/stetic has a format, there’s libglade or whatever, etc. etc. What would be really useful would be a better, more standard, system for writing the simpler apps which don’t require much in the way of custom widgets and things: maybe as well as being able to choose between Gtk+ and Qt at runtime, you can maybe also choose between Flash, or AJAX/HTML – or some other future toolkit which doesn’t yet exist…


News of the Screws cack-handed “the Stig revealed!”


Daily Hatemail spills Stig beans


  1. I saw your post through the pingback on my site. Just to be devils advocate here, the reason you wouldn’t want to abstract away details of the toolkit is that you lose the cohesiveness that made each toolkit useful in the first place. Basically each toolkit developer had a goal in mind and the look and feel basically came out of that goal. Abstracting it away means that you are throwing away all the things that made that toolkit useful. You might as well choose one at that point. Put it this way, Java has a GTK look and feel module, you can still tell it is a Swing app. You can configure GTK+ to look like the mac, it still feels like GTK+. So a toolkit is much more than just the code that runs, it is the philosophy of how applications should be developed which in turn translates into the look and feel of those applications that is very hard to duplicate.

    If we want to get rid of the duplication everyone is going to have to agree on a look and feel goal. Even in that highly unlikely scenario I doubt Qt is the answer. In fact toolkits are quickly becoming obsolete by a standard that everyone already uses – HTML. But that is another blog post for sometime in the future.

  2. Alex

    Hi John, I appreciate your comments. You’re absolutely right, of course, in that the sentiments expressed above are very much an “ideal world”, and there would be issues like look and feel. Something generic would probably end up kind of wxWidgety, but my feeling was more that for many apps the set of widget features you’d be using would be that kind of subset.

    HTML is interesting, but also has its problems – mainly that you can’t easily “push” stuff to an HTML interface. As an example, I have a Gtk+ app I worked on which had some audio controls including a live volume meter: implementing that in HTML would be a nightmare. I think there are also various layout issues which make HTML less than ideal in many ways.

    I do think there is a lot of interesting mileage in widget sets though, in terms of innovation: with stuff like Clutter appearing, it’s clear that it’s not a “done deal” by any means.

Leave a Reply