IOS - which parts of Qt are supported on iOS devices (especially QWebView)?
-
There is no official investment on iOS & Android porting.
-
@ qtnext: I'm currently working on an app to put through the App Store approval process (even though I'll have to yank it as soon as it gets approved due to Qt 4.8 still being under a Technology Preview license) - because really, the biggest and most important unknown with this project is whether it is possible to get App Store approval for a Qt/QML based app. The aim is to get all of this (and the work on the plugin - including Mobility) done by the time Qt 4.8 is officially released.
In terms of licensing, no decisions have been made as yet. I have significant development costs to recoup, and so will need to get some commercial licensees (or some other form of remuneration) before I would be prepared to make the work publicly available under an LGPL or similar license. I have been contributing iOS-specific changes to both Qt (4.8) and the UIKit (proof-of-concept) plugin, and that work is under the standard Qt license (and part of the current 4.8 master).
I have been developing the Qt iOS plugin with a commercial Qt license, and so obviously for myself and other Qt licensees there is no issue with the static linking of Qt. Whether or not it is possible to adhere to LGPL when using statically linked code is a legal grey area. Nokia has assured me that they would like Qt to be "Everywhere" and would not wish to test this aspect of LGPL in court - as long as the other terms of the license were adhered to and source code or linkable object code (for your application) was provided.
-
Now, I made a little StarWars game for iOS (with the open-source UIKit plugin) with images, animations and dynamically loaded (java)scripts.
See:
http://privet.bplaced.com/v/qt_ios_starwars.swf
(the movie is 8 MB large)
(a pure QML game)
So, the basics are working!!! -
Have managed to embed Apple's iOS WebKit into a QWidget, so there is a way forward for web content on Qt/iOS... :) Going to try to match the QWebView API as much as possible (for QUIWebView), but unfortunately it can't be a 100% drop-in replacement (due to there not being an equivalent of QWebPage and QWebFrame on iOS)...
-
@SumWon That's great news. Thanks for sharing this. Any news on the app store approval test?
-
@thomasbonte: Got a bit side-tracked, as I am working with a customer to get their Qt (widget) app onto iOS. I'm going to have to get back on the case soon though... Will post here when there's any news on that... :)
-
-
Three ports? Hm, you mean one in 4.8, old iOS port without Lighthouse (which evan don't have good QtGui support) and closed-source one? For me it looks like we have only one port - which is mentioned in Labs blog post.
-
Hi,
I built now two small Apps for iOS to test the Qt/QML features of the UIKit implementation (Qt4.8)
See:
http://privet.bplaced.net/qsw_ios.png
http://privet.bplaced.net/v/qt_ios_starwars.swf (>8MB!)
http://privet.bplaced.net/qview_ipad.pngMy first remarks:
-
I had problems with QML plugins (=/imports/*):
They aren't working, because Apple doesn't allow
dynamically loaded libs.
I was not able to compile and link these statically
So I'm only able to use the stock QML elements. -
the speed: it's slow if I have more elements and animations
(like the little star wars game with 25 stars each with own animation).
The app swallows sometimes animations.
(see the BOOM-animation after a hit on the video (this works on desktop systems))
The reaction to a touch takes sometimes over 1-2 second! -
orientation is not handled automatically and there is no helper classes for this,
so I have to handle it manually with a lot of Cocoa+Qt-code.
The calculation of the window-size in Landscape mode is buggy. -
size: min. 25 MB This is big!
A normal standard iOS app created with XCode is smaller than 1 MB -
the UIKit-webview implementation seems to be difficult, so I'm using in
this demo the Text element (Text can display richtext/html/pics)
Conclusion:
The UIKIt plugin is impressive as first proof of concept solution,
but still not enough for commercial Apps... -
-
- You have to link the plugins statically. As there is no macro for this (like there is for other Qt plugins), so you'll have to register the plugin's types yourself.
- I haven't run into speed issues, however I'm using optimised settings and a different plugin (on A4 hardware). In any case a mobile device has a much slower CPU and memory subsystem than a desktop PC, comparisons should only really be made with other mobile devices.
- Auto-rotation is not done correctly (yet) in the "proof of concept" plugin.
- The Qt libraries are not built-in on iOS. Of course a Qt app is going to be much bigger, it has to bring the whole library with it.
Conclusion:
http://en.wikipedia.org/wiki/Proof_of_concept ;) -
I mentioned my hints because I find the UIKit (proof of concept) plugin very exciting!
I noticed a lot of people interested in such a Qt solution!I hope, that nokia notices the interest of the community and undertakes some efforts to refine the iOS support
(if the "open governance" model is meant seriously, than they should!). -
The "open governance" model is meant to offload the maintenance of Qt ports to the community. The idea being that if the "community" is interested in an iOS (or whatever) port, then they should do it themselves. The logic is somewhat flawed, as why would anyone spend thousands on hardware and software licenses and countless man-hours on development so that Nokia can improve it's product portfolio for zero cost to itself? At the same time, why would Nokia spend any time or money on developing support for its competitors' products?
For these reasons, it's highly unlikely that the UIKit plugin will be much more than a "proof of concept", or that there would be a high quality "free" port of Qt to any unsupported platform... IMHO, for this model to work, Nokia has to sponsor (ie. pay for) "community" ports (to platforms "of interest") if they are not willing or able to port to those platforms themselves...
-
[quote author="SumWon" date="1317939895"]The "open governance" model is meant to offload the maintenance of Qt ports to the community. The idea being that if the "community" is interested in an iOS (or whatever) port, then they should do it themselves. The logic is somewhat flawed, as why would anyone spend thousands on hardware and software licenses and countless man-hours on development so that Nokia can improve it's product portfolio for zero cost to itself? At the same time, why would Nokia spend any time or money on developing support for its competitors' products?[/quote]
Have you ever considered that Nokia offers you Qt for free? That "thousands on hardware and software licenses and countless man-hours on development" spent by Nokia are provided you for free?
[quote author="SumWon" date="1317939895"]For these reasons, it's highly unlikely that the UIKit plugin will be much more than a "proof of concept", or that there would be a high quality "free" port of Qt to any unsupported platform... IMHO, for this model to work, Nokia has to sponsor (ie. pay for) "community" ports (to platforms "of interest") if they are not willing or able to port to those platforms themselves...[/quote]
Take a look at Necessitas or "Digias latest Windows Embedded port":http://developer.qt.nokia.com/forums/viewthread/10425/. I wouldn't consider them "proofs of concept".
-
[quote author="Lukas Geyer" date="1317978505"]
Have you ever considered that Nokia offers you Qt for free? That "thousands on hardware and software licenses and countless man-hours on development" spent by Nokia are provided you for free?[/quote]I have had an "all OS" commercial license for some years. All those hours of development were funded by me and other commercial Qt licensees. In any case, Nokia does not pay money to develop Qt so that they can give it away for free. They develop Qt so that they can use it on their own platforms (ie. provide a high quality port of Qt to Symbian/Maemo). My point was that they may need to pay something (either by tasking their own developers to it, or sponsoring a 3rd party) if they want to have high quality ports of Qt to other platforms too.
-
You people are going crazy.... Ufffff.. I wonder whether you all are having an extra brain...
I don't know what this porting is all about, and I doubt whether it is as complex as Special Theory of relativity or as easy as Second law of thermo dynamics.. Please somebody make a tutorial, what these porting stuffs, wrapper classes are.. And how only Qt makes it viable for porting?.. Is it because of the assembly code the compiler generates for different OS's?.. Or What is it?.. You guys are coming telling that you are contributing to Qt (porting) like sipping a cup of tea!..
If somebody out there explains this procedure I hope more people will be able to contribute to Qt. I'm also willing to contribute to some open source projects ant let Qt be the first on the list (Actually I tried to contribute to Linux, considering myself good at programming and went on to download the Kernel package after an hour of squeezing-brain activity, I just banged my head on the wall for considering myself a programmer at first :-)).. So I request someone to start a wiki page or something to explain how anyone can contribute to Qt and what knowledge should they have. Whether it is about assembly or c.. Like things..
-
The Qt for iOS SDK has been released now. This includes a workalike QWebView which embeds Apple's WebKit. The 'FancyBrowser' sample at https://qt.gitorious.org/~ianfromafrica/qt/qt-ios-plaszma has been updated to demonstrate its usage (in fact, it's a 1 line change to include the QUIWebView header file in place of the QWebKit one).
-
[quote author="qtnext" date="1312878111"]it's strange to have at least 3 known different port of Qt ios ! perhaps it's time to merge it ?[/quote]
[quote author="Denis Kormalev" date="1312878318"]Three ports? Hm, you mean one in 4.8, old iOS port without Lighthouse (which evan don't have good QtGui support) and closed-source one? For me it looks like we have only one port - which is mentioned in Labs blog post.[/quote]
These ports have (more or less) merged now in the qt-ios-plaszma repository on gitorious. There wasn't a lot that could be salvaged from the qt-iphone project, however some of the GUI work they've done can possibly be used in a future CoreGraphics iOS platform plugin (both QPA plugins currently use OpenGL). The qt-ios-plaszma version of Qt 4.8 adds some APIs to QPA which are necessary for iOS. The version of the 'UIKit' plugin there also has had some extensions, and will probably be the basis for any ongoing opensource work (either by the original author, the qt-iphone project or someone else).