How Qt could bring better third-party software to Ubuntu

Canonical's CTO recently pondered the technical advantages of the open source …

Mainstream graphical applications for the Linux desktop are generally developed with either Gtk+ or Qt. These open source development toolkits supply user interface frameworks and other components that are needed to build desktop programs. Although Gtk+ has historically been favored by the major commercial Linux distributors, Qt's numerous technical advantages and growing relevance in the mobile industry are increasingly difficult for Linux vendors to ignore.

In a blog entry posted this week, Canonical CTO Matt Zimmerman outlined how the capabilities of Nokia's Qt development toolkit can benefit Ubuntu. Some of the specific advantages that he highlights include Qt's strong corporate backing, robust suitability for cross-platform development, and increasingly rich support for touch interaction.

"We want to make it fast, easy and painless to develop applications for Ubuntu, and Qt is an option worth exploring for application developers. In thinking about this, I've realized that there is quite a bit of commonality between the strengths of Qt and some of the new directions in Ubuntu," he wrote. "No single solution will meet all developers' needs, of course, and Ubuntu supports multiple toolkits and frameworks for this reason, but Qt seems like a great tool to have in our toolbox for the road ahead."

As a third-party Linux application developer who has experience with both toolkits, I'd warmly welcome stronger support for Qt in Ubuntu. In my experience developing Gwibber (a Gtk-based social network tool I created that is included in Ubuntu and other Linux distributions), I have consistently been frustrated with the limitations of Gtk+ and its unsuitability for producing the kind of user interface that I want to offer my users.

Over the past few years, Qt has advanced at an extremely rapid pace and has gained some remarkable capabilities that make it radically easy to achieve things that would be exceptionally difficult and time-consuming to do with Gtk+. Qt significantly boosts developer productivity, lowers the barrier to entry for developers who are new to the platform, and offers a much higher level of cross-platform portability. I think that offering Qt as a standard part of the Ubuntu desktop installation would enrich the platform by opening the door for better third-party software.

Qt 4.7, which was released last month, introduced a new framework called Qt Quick that is especially conducive to rapid development. I've been experimenting with Qt Quick myself ever since the earliest experimental versions were made available in public source code repositories. It allows developers to build sophisticated user interfaces with a simple declarative scripting syntax and bind those user interfaces to data models that are implemented in C++. This pairing offers a great mix of performance and productivity that looks to be a good fit for Ubuntu.

It's also worth noting that the Qt Quick declarative scripting language, called QML, can be used by itself without C++ to build relatively powerful applications. This could also be useful for Ubuntu because it would make it easier for users who don't have a lot of previous programming experience to start building their own software. Such a low barrier to entry really meshes well with the vision of user empowerment that is at the heart of Ubuntu's great development tool projects, such as Quickly and Ground Control.

A point that I think often gets overlooked in the toolkit debate is that adopting Qt doesn't necessarily imply ditching GNOME or switching to KDE. As we discussed in our review of Qt 4.5 last year, Qt has relatively robust support for Gtk+ theming, including conformity with the GNOME HIG and support for native GNOME dialogs. When everything is properly configured, Qt applications look entirely at home in GNOME environments. Adding a standard Qt library stack to a fresh Ubuntu installation requires only 16.5MB of packages, which expands to approximately 50MB on disk.

I'm currently working on a tutorial for Ars that will demonstrate the technical advantages of Qt Quick for mobile and desktop development in a more comprehensive way. It's not ready yet, but I want to share a sneak peek in this article to illustrate the kinds of things that Qt Quick can be used to accomplish.

One of the demo applications that I built for the tutorial is a front-end for the RTorrent BitTorrent client. The user interface, which works well on both desktop computers and touchscreen-enabled mobile devices, has some nice animated transitions and pulls the file icons from the user's default theme. Thanks to Qt's portability, I was able to get it working on Mac OS X and Windows in addition to Linux, my preferred environment. I actually designed it with MeeGo in mind, and I look forward to testing it on an N900 when MeeGo is a bit more usable on that device.

The implementation consists primarily of QML layout descriptions, but also has a small amount of C++ code that communicates with RTorrent's XML-RPC API (you can look forward to seeing the complete source code in my upcoming tutorial). It was a weekend project that required surprisingly little effort. These kinds of applications are trivially easy to make with Qt.

Some historical context

Qt, which was created by a Norwegian software company called Trolltech, was originally made available under a dual-licensing model. Open source software developers could use it at no cost, but commercial developers who used it to build proprietary software had to pay licensing fees. This model allowed Trolltech to build a business around Qt that funded their efforts to improve the toolkit, but it created some barriers to adoption for the major commercial Linux vendors. The model later changed substantially following Nokia's acquisition of Trolltech, resolving the original problems that had prevented Qt from becoming the dominant Linux toolkit from day one.

Gtk+ is distributed under the terms of GNU's Lesser General Public License (LGPL), which means that it can be used freely in both open and closed-source applications. The major commercial Linux vendors originally chose to back Gtk+ because its more permissive license allowed commercial software developers to use it without paying a licensing fee. A toolkit that enables royalty-free commercial Linux application development is critically important for attracting a diverse ecosystem of independent software vendors (ISVs) to the operating system.

Qt has always had a modest technical edge over Gtk+, but it was not enough to outweigh the licensing issues during the early days of the Linux desktop. The gap in quality began widening substantially when Qt 4.0 arrived in 2005 with major improvements, however, and has continued to grow rapidly. Although the high licensing costs deterred adoption among Linux vendors, Qt's technical merits allowed it to gain considerable traction among software industry heavyweights. It is already used today by Google, Amazon, Skype, Adobe and many others.

The real game-changer that redefined Qt's role in the Linux landscape was Nokia's acquisition of Trolltech in 2008. Nokia had spent several years struggling to make Gtk+ suitable for mobile environments with the Hildon toolkit for Maemo, but eventually determined that Gtk+ just wasn't going to meet its needs in the long-term. Acquiring Trolltech gave Nokia an ideal toolkit for moving its next-generation mobile strategy forward.

Nokia relicensed Qt under the LGPL last year, eliminating the major barrier to ubiquitous third-party adoption. As I predicted in my article at the time, the move deeply gutted ISV support for Gtk+, especially in the mobile space. When Nokia and Intel announced MeeGo, their combined mobile Linux platform, they positioned Qt as its standard application development toolkit. The once-promising GNOME Mobile initiative lost practically all of its momentum.

Qt can bring third-party developers to Linux

Although Gtk+ still has value and there are a number of reasons to continue using it for building native Linux software, Qt is now the obvious choice for ISVs that are targeting multiple platforms. Qt makes it exceptionally easy to conform to the native look and feel of the underlying platform or build a totally custom user interface that is optimally suited to a target device or form factor.

As Nokia and Intel bring MeeGo to a wide range of devices, it's going to attract some major commercial software vendors. It would be relatively easy for those software companies to bring their mobile Qt applications to the Linux desktop using the same code that they use on MeeGo. Qt is specifically designed to make that easy. This would be a huge win for desktop Linux because it would bring third-party applications that would not otherwise be available.

It's worth noting that some prominent mobile software vendors are already eagerly embracing Qt due to Nokia's support for the toolkit. Mobile video streaming company Qik, for example, is working on an experimental Qt-based port of its popular application with the aim of bringing it to MeeGo.

Gtk+ is not dead, as evidenced by the excellent Gtk+ hackfest that is currently in progress, as well as some of the nice improvements that are coming for Gtk+ 3.0. I'm increasingly skeptical, however, that Gtk+ will be able to catch up with Qt as Nokia continues to push the toolkit forward faster. The factors that compelled the GNOME-centric Linux vendors to favor Gtk+ during the early days of the Linux desktop are no longer relevant. If they want to continue delivering a competitive user experience, I think they need to either significantly boost their investment in Gtk+ or start seriously considering the possibility of making Qt a first-class part of their environments.

The problem with Qt is that it doesn't give a really first class experience on windows and mac. It's the best cross platform solution, but it isn't the best solution.

Ancillary is the issue that Nokia's focused them more and more on symbian and meego, which are (sorry, zealots), respectively a third rate mobile platform and vaporware. Even if they were good though, they're still mobile platforms. You can't have a good cross platform environment that's focused on desktop and mobile. The interfaces are too different. Make it good for mobile and it's awkward for the desktop - have you ever tried using apps in the iPhone emulator with your mouse? It's painful. Write something good for the desktop and it is equally painful on a mobile device - think about applications run through remote desktop or citrix on an iPhone, iPad, or Android device.

My point is that there's only so much development resources for Qt, and they've chosen to focus on mobile platforms. I don't blame nokia, that's why they bought trolltech. And for linux, it's a good option compared to the other stuff.

But for Windows and Mac OS X, the native development environments and tools produce better results. Nokia hasn't focused on this, they've put their efforts towards mobile. And it shows.

If Canonical really wanted to push QT, they'd change their default desktop environment from GNOME to something that uses QT, even if that something else isn't KDE.

The desktop doesn't have to be QT based. The current Ubuntu regime does just fine at exploiting KDE apps.

That's the real kicker. The alternate desktop environment is KDE, not QT. QT apps don't necessarily fit in better with a KDE desktop than they would with a GNOME one. They're still going to be somewhat alien.

The problem with Qt is that it doesn't give a really first class experience on windows and mac. It's the best cross platform solution, but it isn't the best solution.

Ancillary is the issue that Nokia's focused them more and more on symbian and meego, which are (sorry, zealots), respectively a third rate mobile platform and vaporware. Even if they were good though, they're still mobile platforms. You can't have a good cross platform environment that's focused on desktop and mobile. The interfaces are too different. Make it good for mobile and it's awkward for the desktop - have you ever tried using apps in the iPhone emulator with your mouse? It's painful. Write something good for the desktop and it is equally painful on a mobile device - think about applications run through remote desktop or citrix on an iPhone, iPad, or Android device.

My point is that there's only so much development resources for Qt, and they've chosen to focus on mobile platforms. I don't blame nokia, that's why they bought trolltech. And for linux, it's a good option compared to the other stuff.

But for Windows and Mac OS X, the native development environments and tools produce better results. Nokia hasn't focused on this, they've put their efforts towards mobile. And it shows.

I think you're still thinking of Nokia's push for Qt and Symbian in the other article.

This article mostly concern Qt on the desktop. So, instead of thinking 'apps that run on both desktops and smartphones', you should be thinking 'apps that run on any desktop OS, be it Linux, Windows, or Mac OS X'.

The bellwether for Qt-on-desktop is KDE. KDE was never designed for mobility (i.e., smartphones), but damn if it isn't a very good desktop environment.

"Mainstream graphical applications for the Linux desktop are generally developed with either Gtk+ or Qt"

It depends what you mean by mainstream. If by mainstream, you mean the tiny part of the computer market that has used desktop Linux clients in the past, then QT might have a future. But, if by mainstream, you mean something like the 30% share of a commercially important market that Android seems to be currently achieving, then you would be better off forgetting about QT. I have actually developed some very serious software in native C code. I have also done some substantial personal software with .Net. The reality is that managed code is a much more productive environment then native code. If a managed code UI technology ever gains a significant place in the computer market, the only factor that will extend the life of native code UI frameworks is a legacy base of installed software and programmers reluctant to learn anything new. Apple, Win 32, and COM all have that base. QT does not unless your world is circumscribed by those with a history of Linux client use.

I think you're still thinking of Nokia's push for Qt and Symbian in the other article.

This article mostly concern Qt on the desktop. So, instead of thinking 'apps that run on both desktops and smartphones', you should be thinking 'apps that run on any desktop OS, be it Linux, Windows, or Mac OS X'.

The bellwether for Qt-on-desktop is KDE. KDE was never designed for mobility (i.e., smartphones), but damn if it isn't a very good desktop environment.

No, where I work they use Qt for desktop applications. There are zero linux users of the software. It's all Windows and Mac OS X. I recognize there is a community of people who use linux on the desktop, but practically speaking commercial developers do not target linux on the desktop.

So the benchmark is native Windows and Mac OS X applications, and Qt still isn't as good. And with the recent focus on mobile, it looks like it's not a priority for Nokia.

Though im not a developer and can't commit on developing using qt i would say as an end user that it doesn't look good in a gnome/gtk environment. I've download a few applications based on qt (armorak, Skype, among others) the ui sticks out like a sore thumb. Even the screen shot in the article looks bad. I'm not sure if this is the developers fault or the toolkit but in the end i can't see myself using a qt application on gnome. I would much rather ubuntu give funds and man power to improve the gtk toolkit.

Also, I don't see the big fuss about porting mobile apps to a desktop os. mobile apps are usually weak one trick ponies, why would why want something like that on my desktop?

I think you're still thinking of Nokia's push for Qt and Symbian in the other article.

This article mostly concern Qt on the desktop. So, instead of thinking 'apps that run on both desktops and smartphones', you should be thinking 'apps that run on any desktop OS, be it Linux, Windows, or Mac OS X'.

The bellwether for Qt-on-desktop is KDE. KDE was never designed for mobility (i.e., smartphones), but damn if it isn't a very good desktop environment.

No, where I work they use Qt for desktop applications. There are zero linux users of the software. It's all Windows and Mac OS X. I recognize there is a community of people who use linux on the desktop, but practically speaking commercial developers do not target linux on the desktop.

So the benchmark is native Windows and Mac OS X applications, and Qt still isn't as good. And with the recent focus on mobile, it looks like it's not a priority for Nokia.

Ah, I see. Thanks for correcting me.

That raises a question for me, though: Do you think Canonical will be the steward for Qt-desktop? Somehow I imagined Nokia pushing Qt-mobile while Canonical push Qt-desktop.

If Canonical really wanted to push QT, they'd change their default desktop environment from GNOME to something that uses QT, even if that something else isn't KDE.

I already wondered why Canonical chose two completely different toolkits for Unity: Clutter for x86 where accelerated OpenGL is available and EFL for the unaccelerated ARM version.If Canonical used just Qt in the first place, the same code could've been used by both.

The Ugly wrote:

The problem with Qt is that it doesn't give a really first class experience on windows and mac.

Blah. I've seen many oh-so-native .NET apps on Windows whose user experience just sucks. They all look out of place. In contrast to that carefully designed Qt apps look and feel just fine under Windows.Same for Mac OS X: Qt can't do magic. Care has to be put into Qt apps for Mac, like adding document icons to the title bar, etc.

But for Windows and Mac OS X, the native development environments and tools produce better results. Nokia hasn't focused on this, they've put their efforts towards mobile. And it shows.

What is this "mobile"? Aren't netbooks also mobile? Why would the requirements of neetbook apps be any different than desktop applications?Nokia knows exactly that it can't affort to lose desktop developers. Nokia wants all developers to use Qt everywhere because that means that their applications can easily be ported over to Nokia smartphones.

Though im not a developer and can't commit on developing using qt i would say as an end user that it doesn't look good in a gnome/gtk environment. I've download a few applications based on qt (armorak, Skype, among others) the ui sticks out like a sore thumb. Even the screen shot in the article looks bad. I'm not sure if this is the developers fault or the toolkit but in the end i can't see myself using a qt application on gnome. I would much rather ubuntu give funds and man power to improve the gtk toolkit.

Also, I don't see the big fuss about porting mobile apps to a desktop os. mobile apps are usually weak one trick ponies, why would why want something like that on my desktop?

I don't have a dog in this fight, so I don't care one way or the other. But I don't get the reference to the screenshot looking bad (assuming you're talking about the PhaultTorrent demo app) - I think it has a nice, clean interface.

I wish Gtkmm had some serious following as I think that has far better and much more logical an OO architecture than Qt. It implements the best practices in softaware engineering and does so without any funny macros adn proprietary language extensions. It is sad to see it lose relevance compared to these fast-and-quick advancments in these other not-so-elegant tools.

I wish Gnome were written in Qt. KDE's HIg is awful, imo, but I love Gnome's look and feel. Its just that the toolkit is very dated and slow moving. Maybe its time Canonical really differentiated themselves from the rest of distroland and write their own desktop based on Qt. It's not going to happen but it would be pretty cool.

Though im not a developer and can't commit on developing using qt i would say as an end user that it doesn't look good in a gnome/gtk environment. I've download a few applications based on qt (armorak, Skype, among others) the ui sticks out like a sore thumb.

Amarok is a KDE app, therefore, it uses KDE libraries and HIG standards to draw the app.Skype has an intended out of place GUI either in Linux, Mac or Windows. It's an intended design.

saturnblackhole wrote:

Even the screen shot in the article looks bad. I'm not sure if this is the developers fault or the toolkit but in the end i can't see myself using a qt application on gnome. I would much rather ubuntu give funds and man power to improve the gtk toolkit.

If you had more insight about this topic, you would notice that QML and QT Quick are a very different approach to interface design. He is demonstrating a phone/tablet app running on a desktop, without the desktop interface. The major catch is that he could maintain exactly the same codebase and swap the interface with a proper desktop design.

saturnblackhole wrote:

Also, I don't see the big fuss about porting mobile apps to a desktop os. mobile apps are usually weak one trick ponies, why would why want something like that on my desktop?

That's what most people are getting wrong. Coding in QT means that the backend can be the same for every platform, but the interface can change according to necessities. Of course, phone/tablet needs completely different designs, but that's what the new QT features are for!

The problem with Qt is that it doesn't give a really first class experience on windows and mac. It's the best cross platform solution, but it isn't the best solution.

fair enough, but think of the 'first class' apps you get on Windows nowadays written using WPF and .NET, they have nothing like the consistency of Windows apps of yesteryear, all flashy bits here and there with highliting buttons and mouse-over effects, trying hard to make the Windows desktop look like a flash-laden web page.

So, I don't think there's that much of an argument against Qt on Windows anymore. Maybe they could make the widgets look prettier, but then QML should be providing that already.

I find stories like this completely baffling. I am using apps written in QT and also in Gtk and probably lots of other things, on neither KDE nor Gnome nor Ubuntu, and they all seem to run just fine, and if they are different in look and feel, its in the noise.

So where on earth do we get the idea that QT can have something to offer Ubuntu? Ubuntu, for Heaven's sake, its just a Linux distro. It will run anything that any other distro will run. QT has nothing special to offer it. Its not like Ubuntu is going to change something, even that it could change something, to acomodate QT.

As for that idiotic heading, the idea that QT could bring better third party software to Ubuntu???? How on earth is it going to do that? Like, what on earth is it that Ubuntu has to do to allow these better apps, which will by the way not just be for Ubuntu, to run on it?

Do any of these writers have any idea how Linux actually works? Do they realize what a distribution is? Do they understand that Ubuntu is not an operating system but a distribution? Do they even understand that Ubuntu is not equal to Linux?

< OPINION >They may just be my personal experience, but I've found that GTK+ usage greatly outweighs QT usage. Sure there are a number of commercial users of QT, usually older applications that have been around a while which started using much earlier versions of QT (like qt3). I've also noticed that in general if there's a QT version of an application and a GTK version, the GTK+ version is the better application (I mean like for comparable applications like Torrent Programs.) </ OPINION >

I cannot really say that I have THAT much of a dog in the race, because I use mostly small lightweight apps on my Linux machine, and mostly that means GTK+ or something even lower level than that.

I've been using KDE on Ubuntu for about a year now, simply because it saves my terminal window positions.

This. I wish I could get my damn window positions to save instead of have them pop into open space or appear cascaded. As I understand it, GTK lacks the ability to remember window placement information. In a modern GUI world this is unforgivable.

Perforce has been using Qt for the Gui client, P4V. It started off a little shaky, but since then has become a very solid tool which works and looks great on Windows, MacOS, and Linux (which is where I use it all day.)

I was a KDE fan boy, But Aaron and company trashed it with 4.x. They got better technology Qt4, then abused it all to hell. There is no reason why anyone wants to rotate a desktop widget.

I like Aaron and all, but they should have aimed for feature parity of 3.5, with more incremental improvements. I know why they went wrong - they felt like they needed to contend with Windows Vista's Aero. They even ended up doing better than Vista did, but they fractured KDE in the process. There is a reason why I still run the Windows 2000 theme on Windows 7 -- Its all I need.

I don't understand these "2nd rate GUI" comments. There are problems in KDE that the size hints are not correct for some reason (I have yet to see any plain Qt app show this problem) so it looks sloppy. But they are quite function once you've adjusted the size. Finally Qt perfectly draws native widgets so I say its programmer error.

For a while now I've been wishing there was a Linux desktop based on the Gnome philosophies, but built with QT. I think QT is great technology but KDE blows. It feels like a tinker toy for nerds rather than an intuitive, modern OS I can give to my Grandma.

The reality is that managed code is a much more productive environment then native code. If a managed code UI technology ever gains a significant place in the computer market, the only factor that will extend the life of native code UI frameworks is a legacy base of installed software and programmers reluctant to learn anything new. Apple, Win 32, and COM all have that base. QT does not unless your world is circumscribed by those with a history of Linux client use.

I believe you're ignoring a crucial data point: Most development on both Mac OS X and iOS uses Objective-C, which isn't a managed language. The Objective-C runtime library is fairly safe, but the language cannot be, as the syntax is a strict superset of the C syntax.

Seems pretty unlikely to me that any of the big GTK supporters, whether they be distros (Ubuntu, Fedora, etc) or the Gnome desktop, would ever switch to Qt. There's too much risk going with a toolkit that is managed internally by a single company. Correct me if I'm wrong if Qt development is different than this.

Okay, first of all, Qt uses native platform APIs to draw its widgets as much as possible, so the apps looking native is a matter of complying to that applications HIG, something that would be up to application developers regardless of toolkit or language. Additionally, Qt's MVC development approach should readily allow developers to keep their logic in tact and recreate appropriate interfaces for each platform (with full HIG compliance). Additionally, there are arguments to made for managed and native code. And I would argue that lower level services and toolkits should be written natively to avoid what can become serious speed bottle-necks. And yes, C++ is the primary supported language for building Qt apps. However, support for other languages is just a matter of bindings, so if a developer wants to write Qt apps with managed code, they can. For instance, fully supported Python bindings are being developed (PySide) and more mature third-party ones already exist (PyQt). And finally, Qt is a third-party toolkit, it can't be expected to be entirely compliant on a platform that uses completely separate technologies. Not to mention Qt is much much more than just a UI toolkit, it provides fantastic libraries for XML, database interaction, multi-threading, D-Bus interactions and many more. And if you think that Qt is insufficient for desktop app development and Nokia just isn't putting in the effort, I would ask you to provide an example, because otherwise there not much of a discussion to be had anyways, is there?

I've used .NET and have been using Qt for the past two years in my job and I personally prefer Qt over .NET. That would be just my opinion. I just want to let some people know that there are already a lot of mainstream applications that use Qt on both Mac and Windows OS. Autodesk, Google Earth, VLC media player, Virtual Box. I'm fairly sure people on this site have used one of these applications before. These all seem to be professional applications developed using Qt. Established programmers are already comfortable using their preferred development tools. If ubuntu was to install QT Quick and QML as well as a tutorial on the default installation, I would love to see people get interested in programming through these devices.

There is very little in terms of features in .NET that you can't do in Qt so I'm not biting the managed code is better line. Qt also can run faster than managed code can. Also, I tend to see a lot of movement from GTK+ to Qt. The moblin folks dropped GTK+/Clutter for Qt when they moved to MeeGo and haven't looked back from what I can tell. Maemo and OpenMoko did the same thing. Nokia apparently liked Qt so much that they bought the company (trolltech).

I'm using Qt Quick right now at work and I'm actually enjoying it. It's really well thought out and very powerful.

Seems pretty unlikely to me that any of the big GTK supporters, whether they be distros (Ubuntu, Fedora, etc) or the Gnome desktop, would ever switch to Qt. There's too much risk going with a toolkit that is managed internally by a single company. Correct me if I'm wrong if Qt development is different than this.

No it's not the fact that QT is owned by Nokia that matters, it's the fact that there is tremendous amount of work that has gone into Gnome, GTK and the related software to make switching to QT much sense.

QT may be better then GTK, but the reality is that languages and widgets are much less valuable then programmers want to admit. GTK2.x is now a old and mature platform with multiple decades worth of work behind the software that that uses it. QT4, on the other hand, is really a new platform since it broke compatibility with older QT versions.

If a decent QT-based desktop gets created and new software starts getting written in QT then I believe that there will be no problem with distros like Ubuntu migrating away from GTK. But unless that happens and users begin to demand it then it's just not going to happen.

This is just another example why backwards compatibility is often more valuable then better design.

And it's not like GTK/Gnome folks are standing still. There are very few platforms that can get good programs cranked out faster and easier then various GTK/Gnome components + Python. Ironically all the work that was put into slimming down Gnome/GTK components and cleaning things up to make them run acceptably on a smartphone has made Gnome better then ever and faster then it ever has been in the past. All that stuff is the 'Gnome 3.0' which is already showing up in things like Ubuntu 10.4 and 10.10 (which in my experience is pretty damn slick)

Going to QT for the mobile platform Maemo may make sense from a developer's perspective, but it's definitely a big set back and they may have missed the crucial couple of years that they could of been competitive with iOS and Android. Only time will tell, but getting products out there in the real world was utterly critical and Nokia may have blown their chance by trying to justify their purchase of Trolltech.

For system's with signed apps, like on the iPhone, how can this be used? My understanding of the LGPL is that any code compiled into the same binary as the library needs to also be licensed under the LGPL and made available, and the end-user must be able to build the library and replace the one used by the application.

While you can make an iPhone app that follows the first part [either link together in a single blob or keep Qt as a separate library just linked to the app], but the second part, permitting the end-user to replace/update the library can't be done, as the entire app is signed and verified so it can't be modified.

For system's with signed apps, like on the iPhone, how can this be used? My understanding of the LGPL is that any code compiled into the same binary as the library needs to also be licensed under the LGPL and made available, and the end-user must be able to build the library and replace the one used by the application.

Your sorta right. First you need to do is look specifically at the QT license. They probably have exceptions you can take advantage to work around these sorts of problems.

But even then if your only choice is to use a static binary then you can provide the object files of your program to the user. That way you can still keep your source code secret, but the user can still finish the compile process against the QT source code.

I believe. I am not a lawyer.

As far as the iPhone DRM goes.... Apple sucks. Will they even allow QT applications in the app store in the first place? From what I understand you need to be using the native objective C stuff.

I wish I could get my damn window positions to save instead of have them pop into open space or appear cascaded. As I understand it, GTK lacks the ability to remember window placement information. In a modern GUI world this is unforgivable.

I wish I could get my damn window positions to save instead of have them pop into open space or appear cascaded. As I understand it, GTK lacks the ability to remember window placement information. In a modern GUI world this is unforgivable.