Qt 5.1 Adds Android and iOS Support 81
colinneagle writes "This week, the team at Digia rolled out the first alpha release of Qt 5.1, which is slated to have the first round of support for Android and iOS, with full support coming in 5.2. The goal is to make 5.1 completely usable for building complete, shippable apps for both mobile platforms. That means Qt can now be used to build native, smooth applications on Linux, Windows, Android, iOS, MacOS X and even BlackBerry 10, all with an excellent integrated development environment – QtCreator. Coming with version 5.1 is also something called 'Qt Quick Controls' — which is a set of nice, reusable user interface controls. Currently, it is focused on Desktop applications, but is expanding to add touchscreen-specific features. And, importantly, this release also brings 'Qt Sensors' into play. 'Qt Sensors' are pretty much exactly what they sound like — access to hardware sensors on devices where they are available, with built-in motion gesture recognition. Definitely a big plus for Android and iOS applications."
Re:Not native (Score:5, Informative)
Re:Not native (Score:1, Informative)
Native App [preeminent.org]
Qt App [tug.org]
There are huge differences. Qt doesn't do tool bars correctly. The text isn't aligned correctly in the ring menu. It uses a non-native widget to resize the tool bar. The icons look all out of place, doesn't used the native platform standard icon for the printing.
Re:How heavy is it? (Score:5, Informative)
That's for everything. Every window decoration you could ever want, every button, etc...
If you strip out everything that's not being used by the current program, you get something that's much smaller.
Re:How heavy is it? (Score:5, Informative)
On Win platform:
QtCore 2.6MB, QtGui 8.5 MB, QtNetwwork 0.9MB, QtOpenGL 0.8 MB, QtWebkit 13.1MB
+ MSVC++ Runtime libs: 7MB
So it is in the few 10's MBs range
Re:Not native (Score:5, Informative)
Native controls means more than to have the same look, if that is the way to measure "nativeness", then Java Swing UIs (Windows/GTK L&F) are native because they call platform theme APIs.
When a toolkit draw controls by itself, the applications normally lose a lot of UI functionality, for example, if Android/iPhone controls add proper default assistive technology metadata to their controls, the toolkit (QT in this example) need to do the same for each control they draw, because the OS don't see buttons as buttons, It see them as a custom control. If the platform control change behaviour in a new OS release, the QT control will not see it, for example when Windows added default context menus to the text fields, self drawed controls don't expose that behaviour until applications are updated with a new version
Re:Not native (Score:5, Informative)
Unfortunately - on platforms where Qt isn't the native UI already - Qt just emulates (draws) the native UI, it doesn't actually use the native UI controls.
On Windows, Qt does a very good job of emulating the native UI. But then again I'd argue that Windows has few truly native UIs. You always notice small differences in how controls behave between different apps. I guess all the different versions of MFC, WPF, VCL, WinForms and whatever implement controls slightly differently from what the Win32 API offers and even between different versions of itself. But users are used to these inconsistencies, so no big deal.
On OS X, the situation is unfortunately a lot worse, probably because Cocoa is so different from everything else that it's hard to emulate properly using primitives from other toolkits. For example you can notice that Qt draws the focus border around buttons differently than Cocoa does. The biggest difference being that Qt buttons are focusable but Cocoa buttons are not. Toolbars also look different: in Cocoa they blend in with the window title bar. Qt doesn't do this - the toolbars look very much Windows-like. The border spacings and alignment are also off. Developers often don't take time to align and space all the controls properly to give them a Cocoa look.
Re:Lots of great new stuff! (Score:0, Informative)
Re:Not native (Score:5, Informative)
The problem with a lot of native controls is that they are hopelessly limited in what they can do. For example, on Windows the classic controls can't really be used outside of a classic application - not without a huge amount of kludgery. When you get to modern UIs on Windows, you get WPF and that doesn't reuse any native control code AFAIK. It just re-implements everything and the kitchen sink -- just like Qt does (correct me if I'm wrong, please).
With Qt, you can rather trivially render the controls offscreen, generate mock events for them, etc, all in a cross-platform way. With native controls, you're pretty much stuck with whatever functionality is there and there's no way to use them any other way. If the platform doesn't provide a blended rendering model for the UI, you can't get that functionality using native controls. If the platform doesn't provide for an easy way to decouple the controls from a physical screen under control of the OS apis, you can't use them on custom LCD screen attached via USB (a screen otherwise invisible to the OS as a screen).
Yes, it would be possible for Qt to do more to cleanly run native controls behind the scenes so that "arbitrary" changes in behavior would propagate. This would most likely be way too much work for the limited benefit it provides. It may well be that whatever services the OS provides behind native controls can be rather simply reproduced in Qt proper. Yes, it requires tracking the platform you claim to support :)
Re:QT is a flawed implementation of cross platform (Score:5, Informative)
Sorry but you're full of it. Hate to break it to you but that's how all UI libraries work by definition! On Windows there is no standard widget set that everyone uses, an no agreement on how a widget should behave. Every framework has their own. MFC, WinForms, whatever MS Office uses, Wordperfect, etc. They all have their own ideas of what a widget looks like and does. MS Office has traditionally shipped it's own widget set with every release. Buttons, scroll bars, dialog boxes, the works. All of these uis use the Windows Theming API to give them common bitmaps to draw, and Qt is no different. Thus a Qt app absolutely looks and acts as good as any other widget toolkit on Windows.
On Mac also, Qt uses the Cocoa native apis to draw widgets, and then tries very hard to follow Mac standards to make them act natural, and to a very large extent they succeed. True on Mac people's idea of fidelity is at a very high standard, or so I've been led to believe.
Maybe your experiences have solely been on Mac where the fidelity wasn't as good in the past. I can tell your experiences with Qt were not on Windows, though.
On linux, of course, well Qt does its own thing, unless you have it use Gtk themes, where it does a very good job of looking and acting like my other Gtk apps.
In short you are definitely wrong about Qt. If you're right about Qt, then Winforms, MFC, MS Office are all just as unacceptable as Qt, as far as look and feel goes. There is no other way to do cross-platform ui toolkits. Don't even mention wxWidgets, because wxWidgets just thunks through to yet another toolkit, though it's provided by Microsoft on Windows so you would probably argue it is the one true widget set, even though precious few applications use it these days.