Nokia bought Trolltech in early-to-mid 2008 (initial offer announced in January, purchase finalized in June). The iPhone SDK had been announced in October 2007 and been made available in February, Android 1.0 would only be released in September (though the beta had started in November 2007), the Windows 7 RTM would only happen in 2009 and W7P in 2010 so the Windows world was still "old windows" (on which regular Qt worked) and Windows Mobile 6.
One can easily assume that, as soon as the deal was announced and likely to go through, Trolltech had little reason to work on porting Qt to non-nokia platforms (out of the 2 months or so they'd have had for the Android beta, and negative 2 months for iOS).
And once Trolltech/Qt was part of Nokia, why would Nokia fund Qt/Android or Qt/iOS? The original plan was to build Nokia's own "next-generation platform" Maemo with it after all.
As to third parties, they did attempt porting Qt (ultimately fizzling out, for the most part):
> And once Trolltech/Qt was part of Nokia, why would Nokia fund Qt/Android or Qt/iOS?
Actually, I expected they'd do exactly that, and was disappointed when they didn't. It's basically the same reason why Sun created Java. They made Java so that software developers could make software that ran on Windows and Linux. Oh eh, and on Sun computers. Which were very much losing the server OS wars at the time. You might say that Java didn't save Sun, but I like to think that maybe instead Java postponed its demise by many years.
I think the same could've happened with Nokia. If Nokia sponsored the best way to make fast, snappy, great apps, in little time, that work comfortably and with a native feel on iOS and Android (oh eh, and also Nokia's current OS hobby), people'd churn out Nokia versions of their apps without much extra work. This might've significantly increased the app ecosystem for Nokia phones, which might have made more people buy the phones. A lot of people (and very much not just the geeks) do care that their favourite apps are supported and decent on a particular handset.
I never understood why they didn't do this. At the time when many developers were still a bit nervous about learning Objective-C just to support one single platform, a good, company-supported Qt-for-all-phones could've made Qt the leading app toolkit by far. Qt sure had the head start, Nokia sure had the resources, and the Qt team sure had the skills. Sad.
Were you following Qt closely, to know about all these Qt attempts? It's a shame that Qt on other platforms didn't work out... It would be a nice alternative to HTML5 and iOS and Android defaults.
I wonder if native UI rendering APIs will be available for these platforms. Will this be a simple wrapper and compile with few native hooks, like Flash on iOS? Or will they take a more integrated approach?
Qt without native UI isn't Qt. I am very interested to see how they will manage to handle the difference in UI concepts between the three mobile platforms.
I might be slightly out of date, but IMHO Qt has always only emulated the look and feel of the platform it was running on by painting all their widgets on their own. While the themes were certainly very good (much better, than, say Java/Swing's "native" themes), Qt apps still left that uncanny-valley feeling.
I can verify that your information is out of date. The widgets are to varying degrees actually native or drawn with OS functionality for drawing native widgets.
However, this is not all it takes to escape the uncanny-valley feeling. For example, the dialog layout still has to be correct, and lots of developers don't make the effort to achieve this.
I would have to second the developer problem. You can have a perfect cross platform UI toolkit, but if the developer doesn't take effort to make it fit everywhere it becomes off. A simple example was message box's. Qt has the ability for you to tell it which button is "yes" and which is "no" and then it will automatically swap the order depending on which desktop environment it is running in, but if the developer just hard codes some strings for the button text there isn't much that Qt can do. Same goes for file menu shortcuts, etc
How many times have you seen an app that is suppose to look 100% like an iOS app badly ported over to android where everything "works", but doesn't fit in.
Out of all the cross-platform toolkits Qt is the absolute best. For example, the Windows themes are literally flawless. It also takes into account so many things that other toolkits don't: native (file picker) dialogs, proper button order, paddings, etc.
That's because on Windows and OS X, Qt uses the operating system to paint native widgets, and uses the corresponding helper dialogs provided by the system.
Yeah, I want to see that too. The UI differences between the platforms go far beyond chrome and metrics. An app that runs on three platforms may have a different set of views and different navigation logic for each.
Its really hard to get running. Supporting android and allowing cross platform QT based applications would be an amazing step in the right direction for QT, and quite frankly, android.
Nokia did excellent work on Qt 4.x, QtQuick/QML and QtCreator/QtSDK as well as a lot of the work for the upcoming Qt 5. Saying they did nothing with it for a few years isn't at all true and is not a fair statement as they did a lot of great work on Qt. Not to mention that they were the ones who released it under the LGPL!
Having said that, I'm both extremely happy and excited that Digia have bought Qt entirely and that they plan to support both iOS and Android, something I've been wishing would be supported for a couple of years now but didn't see as something that could happen under Nokia's ownership.
I wish QT Creator will have built-in support for Python (along with PySide), I really like that IDE, it's really well designed for its sole purpose with a minimal UI (when being compared with Visual Studio).
Power of QT + Productivity of QT Creator + Simplicity of Python = Amazing, IMHO.
PySide-powered python scripts can be frozen into binaries with various tools such as cxFreeze, that's a good thing.
BTW, QT Creator is one of my inspiration sources for my new text editor with a Firebug-like UI for testing css/html in real-time (http://liveditor.com).
You could always add a Python/PySide module/plugin for QtCreator. It has pretty solid (though slightly underdocumented, sadly) plugin support and you can do fantastic things with it. It's also an open source project, so nothing stopping third parties like yourself from adding missing features.
Having said that, if Digia were to officially support Python/PySide in QtCreator/QtSDK, that would be really really awesome.
I wrote a Qt Creator plugin a while ago that does code completion, tooltips, navigation, etc. for Python source code. I never did anything specifically for PySide but it might be fun to try: https://github.com/davidsansome/pyqtc
Is there already a nice way to do the freeze under OS X? I vaguely remember a simple hello world app being 50-100MB, as the tools had no clue which parts are actually needed.
The Finnish stock exchange press release also says
the deal has a "neutral effect" on Digia's earnings
so seems they got it for a pittance, or maybe did some
kind of more complicated hedged deal?
That's true, there are risks, but at least Digia's finances are directly tied to the commercial success of Qt, so their survival depends on Qt being successful. The problem with Nokia was that Qt and Maemo/Meego were internal political footballs that most of the people doing the kicking had no vested interest in.
Doesn't look like Qt business is a big slice of Digia.
They look like a big multinational IT house.
At http://www.digia.com/en/Home/What-we-do/ it's only mentioned at the far bottom of the page...
Now the question is how much actual development Digia can actually afford to keep.
That's my concern as well. Hopefully they will develop it and not just do token work to prevent the license from going to BSD. They may also just be trying to protect their previous investment by keeping Qt with a pulse.
IMHO Nokia has really managed to alienate developers with their treatment of Qt, and their dumping of Meego in favor of MS. This may cause deep repercussions in the long run.
Having been heavily into Qt before Nokia, I see this very differently. Nokia had no idea what they were doing with Qt and the Mobilin/Maemo/Meego and now Tizen projects were a farce from start to finish. I'm sure as strategies they looked good in Power Point, but they clearly had no clue how to turn them/it into a credible consumer OS. They very much remind me of the bumbling, bullet point oriented aimlesness of the failed OS projects of the 90s - Taligent, Pink, Cairo, etc.
However, now Qt is in the hands of a company that does seem to understand the technology and has a realistic and executable business plan. That's a good thing.
Have you ever used a meego device? The N9 is a solid phone, and at time of release Harmattan was far better than the Android offering. What makes you say "they had no clue how to turn it into a credible consumer OS"? That seems to be exactly what they did.
It took them far too long to do it, though. They didn't focus on it, and they had at least three public hardware revisions before they even tried to tack a phone onto the platform. In order to make it credible, they needed to put a lot more weight behind it.
They could have beaten Android by 3 years, but didn't because they were organisationally incapable of doing so.
I'm not disagreeing it took them too long and they did it in a ridiculous way, having already made the MS deal, but I don't understand how you can still say it's "not credible". Go use it.
I think they were doing fine until they got joined up with Intel. Drove the nice Maemo stuff to the ditch with the failed attempt to merge it with Moblin (-> Meego).
Intel and Microsoft... good partners - but only with each other :)
I don't understand this unthankfulness, didn't Nokia relax the license to LGPL and employ, i.e. pay quite some people during their 4 years? Also now it looks as if they act responsibly, no hire fire mentality at all.
Sure, my comment was about Nokia, not Qt. I love Qt, and will keep using it whenever the opportunity arises. Overall, I'm happy about this development because I really care about Qt, and I care very little about Nokia (for me they're that company that makes nice $80 dumb phones for my grandpa to use. But there are tons of companies like that...)
This is probably the best news that can come out of the situation. It's someone already in the community, and familiar with the needs of the platform going forward.
With this acquisition Digia will have an increasing responsibility to the global Qt community, not just the commercial licensing business. We believe in the power of the Qt dual license. It is a great value for Qt that it can be used under an open source and commercial license, since customers have different needs and the licenses have different purposes. Digia wants to continue the good co-operation with different individual contributors and companies working together in the Qt Project. We also are committed to continuing the special relationship Qt has with the KDE community via the KDE Free Qt Foundation. We believe that this symbiosis is valuable for everyone involved.
You can't un-LGPL something that's been LGPL'd (edit:though you might have to fork). Plus Nokia made a legal covenant with the KDE folks that guarantees Qt stays open, and has failsafe clauses that auto-BSD licenses it if the terms of the covenant are broken.
How bad that would be remains to be seen. It highly depends on how much external work from external contributors is going into qt. if most of the work comes from internal employees, then the BSD fork that was auto-created will stagnate while they can add all the cool stuff to their commercial offering.
They could then proceed to make their maintained version as incompatible as possible to the open source version.
The outcome will likely be a very two very different versions of a toolkit.
One based on BSD qt, maintained by the KDE project, more and more losing its cross-platform features (why would KDE care about platforms it doesn't run on).
The other will be the commercial continuation of old qt. Incompatible with the open source version, but keeping its cross-platform features and seeing heavy development and feature additions.
Of course this is just speculation, but it is at least conceivable.
Technically yes; but the KDE side of the board wins any ties[0]. If KDE feels it's best to BSD it (don't see a logical reason why they wouldn't), it will happen.
Gods have finally heard my prayers. What have they been waiting for all this years?