"Qt 5 delivers a step function increase in performance, functionality and ease of use and will be the platform on which full Android and iOS support will be delivered during the coming year."
I've heard people mentioning they already have Qt applications in both App Store and Google Play, but I don't know any specifics. So I suppose the support is there with some tweaking already.
And of course Qt will be the main SDK for both Blackberry 10 and Jolla's Sailfish.
There is Necessitas Qt 4.x port for Android that is pretty solid and was contributed to Qt Project quite recently (http://blog.qt.digia.com/blog/2012/11/08/necessitas-android-...). I have not found good iOS port when I was looking for one. At least for BlackBerry it already is - you can write Qt apps for BB10/PlayBook OS just now.
Didn't know about Sailfish. Interesting that they're focusing on multitasking.
It made me wonder whether BeOS might not make a great mobile OS. Designed for limited hardware, excellent multitasking, and an opensource version in alpha status now.
Achieving UI responsiveness under heavy load is not particularly challenging - the Amiga did it well too, without much effort:
Put UI handling in separate threads/processes (Amiga "Tasks" would've been processes in a memory protected OS, but since AmigaOS isn't, for all intents and purposes a Task behaves like a thread in modern OS"s), and prioritise input and UI control handling threads higher than others.
Lack of UI responsiveness under load in modern OS's is down to laziness - this was largely a solved problem 20 years ago, on hardware magnitudes slower.
It's not particularly challenging theoretically, and yet it is so seldom achieved that it is very sad.
My old iphone 3G stalls for seconds at a time due to memory pressure; Windows stalls for seconds at a time due to CPU pressure. So does Linux with X; I have no experience with Android, but I'd be surprised if it is different.
So apparently, it IS a challenge, even though there is no rational explanation why it should be.
The achieved the latter by making "the right way" also be "the commonly-used way"
Be Inc did 2 things well in this regard
* They designed their API/App Framework so that launching threads was easy, and passing messages between threads was safe & easy
* They developed a culture (both within the organisation and also within their developer community) of using those features everywhere.
Those two things are more closely linked than they may appear. The framework was explicitly message-based. You interacted with different components by sending and receiving messages. And it was heavily threaded (Be called it "pervasive multi-threading"), to the extent that every window had its own thread, separate to the main app thread.
By having those features, and not having any particularly good way to write apps except by using the official framework, the developer community was forced to learn how to develop multi-threaded, message-passing apps.
And once developers started to think in terms of messages and threads, it was natural for them to use those elements to solve all sorts of problems, so that no self-respecting BeOS developer would ever think to do significant processing inside any of the UI handling threads.
Garbage collection was left to the application, the way it is on iOS before v5 (if I'm not mistaken), C, C++ and many other languages. While it does increase mental load on the developer (compared to gc languages e.g. Lisp, Java, C# or Python), it is not too hard. It's still the norm in C++, for example.
And like node.js, they tried to avoid blocking APIs (and mostly succeeded), but provided a very simple way to "outsource" them to other threads. You can do that in C or Java as well, but it's not as easy or as pervasive as it is in BeOS.
The issue is not that it is a challenge, but that modern OS's inherited a different approach:
Windows and Unix app developers have been used to doing everything on the main app thread, and everything is geared around that.
The Amiga couldn't afford to do that, as the machine was so slow that the UI would be unbearable. Modern OS's get away with an architecture that makes it ok to be lazy, because the machines are fast enough that it's just an annoyance.
Consider for example, that to make cut and paste fast on AmigaOS, one "Task" (thread/process) would send a message stating what parts of it's UI data it wanted copied to the clipboard. Another task would then copy the data, and confirm and write the data to the clipboard. Why? Because the clipboard could be on a very slow device (in theory on a floppy, though usually no slower than a slow harddisk).
AmigaOS was infused with design decisions like that: UI "gadgets" (widgets, buttons, whatever you want to call them) using the basic Intuition (AmigaOS GUI) functionality would largely be handled in a separate high priority UI task. Keyboard and mouse input were handled by separate high priority handlers. Window rendering were given high priority.
Something as simple as the terminal / shell which in Linux is typically a terminal application talking to X, in AmigaOS consists of several components, each running in it's own task, some of them providing services that can be reused:
- an input handler, processing keyboard entry, which sends messages to the console device.
- The console device provides a stream oriented read/write interface that hooks a keyboard and mouse to a rectangular section of a Window (you can attach a console device to any window to get an ANSI/VT100 like terminal). It provides the text rendering, and "cooks" the keyboard input into escape sequences etc. It exchanges messages with the console-handler.
- The console-handler, which provides a higher level wrapper around the console.device, providing additional services such as command line editing, history, and manages the window the console.device is instantiated in. In AmigaOS you can open a console-handler by writing to the special filename CON: which will open a console window for you and give you a file handle to interact with it.
The shell is comparatively "dumber" than on Linux as a result of this structure, as the console-handler is expected to handle most stuff like line editing.
A typical AmigaOS app - even if the developer did not take care to thread the app explicitly - would usually end up splitting it's processing over many threads by virtue of making use of OS services that were explicitly message passing, and where stuff dealing with the UI would get priority.
It made it very easy to ensure the UI remained responsive, and was a cornerstone of a lot of the early OS friendly demos of Amiga features: Run whatever you wanted in multiple windows. The OS would still always prioritise the stuff that would make user-interaction feel snappy, unless you actively worked to prevent it (doing your own component rendering in your apps main thread, for example, like lots of modern software ends up doing by virtue of stupidly lazy frameworks...)
That's a fine description. I would like to add that those Tasks were actually co-operative, rather than pre-emptive like modern threads - at least in the versions of AmigaOS I had a chance to use. I think that was also true for multiple processes until AmigaOS 4 or so.
These features were available in libraries on other platforms since forever (I remember a Herb Schildt book from 1988 that presented an implementation in C for DOS!), but were culturally ingrained in the Amiga, and are still essentially fringe in other ecosystems.
There's a trend back to it, at least in the mobile world.
To the extent that Microsoft removed all blocking calls from the API, forcing the programmer to use asynchronous APIs (which, admittedly, works well enough given language advances).
I'm pretty excited about this. I probably won't use it for the UI. My desktop apps are written in Qt, so it will be nice to be able to reuse a lot of back end code. I was using Qt's serialization (probably not the best idea in the first place) to store my data files and I had to redo all the serialization so my iPad version could create compatible data files.
People from hacker news, check out qtquick or QML, it's like html but without the legacy and the bad parts, just powerful syntax for developing apps, and thanks to network transparency QML can be downloaded from the web also.
QT5 is a dream come true, and when it becomes omni-deployable (android, ios, raspberry pi) it will be even better.
Qml is much better than html, thanks for anchors, transitions between states, animation and etc. One remaining thing I just waiting for fully usable version of desktop components.
Qt5's QML2 is using V8 as the JS engine and an opengl es2 scenegraph, so it's actually quite fast. Depending on your embedded platform, you should still be able to achieve pretty impressive performance.
Um, okay. Can you point me to a MIPS implementation of V8 that runs well on a 360 MHz R1 architecture? Oh and my CPU doesn't have any hardware OpenGLES acceleration. How should I work on that?
fortunately or unfortunately the future will require all gui capable computers to have hardware accelerated graphics. To compensate for bad drivers there will be fallbacks to somewhat fast software rasterizers like llvmpipe.
>Um, okay. Can you point me to a MIPS implementation of V8 that runs well on a 360 MHz R1 architecture?
Umm, okay, can you point to anyone that mentioned that Qt5/V8 would be good for those chips? It's not like anyone came in the thread writing that "Oh, QT5 javascript scripting would be great for my 360 MHZ R1".
Oh and my CPU doesn't have any hardware OpenGLES acceleration. How should I work on that?
You shouldn't and nobody said you should. Just like nobody said it would be fine to program Big Blue with, or Arduino.
Depends what you call "lower-end embedded". Even on a mildly modern ARM SoC like the Freescale iMX series, QML works very well, and the OpenGL acceleration makes for an incredibly smooth UI. Also, the backend is still C++, and any computationally intensive tasks should be done there.
Sure, you will take a runtime performance hit if you do a QML UI because all the QML needs to be parsed.
But then again, no it's not all javascript and no it will not suck up all of your CPU. When you write simple bindings (for example someProperty: otherPropert ? "yes.png" : "no.png") the QML engine actually detects these simple cases and doesn't invoke the javascript interpreter when it needs to evaluate the expression, but handles it internally instead. Also if you don't want to do things in javascript you really don't have to as calling QObject slots is super easy. If you stick to simple bindings and write your logic in C++, the javascript interpreter won't have much to do.
>QML is nice, but make sure you have the processor overhead for it. It's all javascript and the interpreter will suck up your processor time.
What professor overhead? It's 2012. Our quad core processors sit idle most of the time -- and even those in our phones aren't particularly challenged.
Plus, what "interpreter"?
For one, V8 uses JIT, second, it's way faster than Ruby/Python (languages that are also used for app development), and in Qt5 V8 is just the logic layer, the GUI/scene-graph parts are C++ and accelerated.
For people doing lower-end embedded stuff Qt5 isn't going to give you much, if you can run it at all.
Well, DUH! Who said anything about them? These people can't even afford to use Java or C#, much less V8 bindings for a UI toolkit, and even the C++ Qt5 part is not targeted to them anyway.
"and even the C++ Qt5 part is not targeted to them anyway."
Thanks for reinforcing my point. Qt5 is more of a smartphone platform than a GUI toolkit for embedded systems now. There are still a lot of low-end chips that need graphics toolkits and the new whizbang stuff just can't work on these systems. Don't tell me QML2 is great for prototyping GUIs when I can't even run it on my platform.
I completely understand why the switch in focus came along, especially when Nokia took over. I still have bug reports from 2-3 years ago that have been marked "don't care, won't fix" by Nokia. My anecdata comes from actual years of experience making Qt work smoothly on lower-end hardware.
So I see that there is the open source project Qt-Jambi, which provides java bindings into Qt, and apparently has a "generator" for working with future versions of Qt.
Assuming it comes up to speed with Qt5, I'd like to try this with clojure.
Anyone have any experience with Qt and Java/Clojure?
I tried it out a few years back. Using it from clojure was a bit painful at the time but you might have more luck today. Qt-Jambi relies pretty heavily on Java introspection eg scanning the fields of a class to find things of type Slot. I also had to write my own repl because UI actions are only allowed to happen inside the event loop thread. Check out github.com/jamii/inkling for some examples which may still be relevant.
i've just discovered eql [http://password-taxi.at/EQL] and am in the process of porting a clojure/swing project of mine over to common lisp/qt. so far it's been a good experience. [i considered qtjambi, but it gave me some compilation problems on arch linux, and i figured this would make a good excuse to learn common lisp]
I've really wanted to dive into this for a side project. On the limited time I've had, I notice the Creator IDE UI and tutorials take an extra step I'm not used which is probably from translating the experience from Finnish to my own language (American English). Just a random guess but the commercial version could increase uptake by doing a round or two of "visual/workflow qa" for a wider-range of global users (especially the folks looking to speed through to working QML/JS demos). Will keep digging ... the "deploy local windowing" to Lin/Win/Mac looks truthy. (I think I should just start simple with a text editor and the compiler next go round)
if you want to play with it and learn your way around the api, it's easier to get up and running with python+pyqt than with c++. the python bindings are very well supported and there're lots of blog posts and tutorials out there.
yep. see http://www.riverbankcomputing.com/news/pyqt-496. the pyqt bindings are supported by riverbank, which offers commercial licenses, so they have every incentive to keep it up to date.
There is a book out there called "Rapid GUI Programming with Python and Qt The Definitive Guide to PyQt Programming
by Mark Summerfield" Code downloadable here:
http://www.qtrac.eu/pyqtbook.html
In all the code in that book you can just substitute "import PySide" for "import PyQt4" and pretty much everything works. In addition, if you install Qt4Assistant you will have a searchable tool for all classes and documentation.
Qt's "Write once, deploy everywhere" has been able for many years on the desktop, until mobile revolution came with incompatible interfaces and now we have to start again. Good news they are working on a solution to this challenging problem!
From the announcement: "Migrating applications developed against the previous Qt version 4 is straight forward, mainly requiring a simple recompilation." So, I suppose that the PySide bindings will be ready in no times.
By the way, it's a code generator, not a preprocessor. Everything you write is valid C++, it's just that there is additional code being generated that interfaces with your code.
The new signal-slot syntax for Qt5.0 [0] really makes a lot of sense when combined with new c++11 lambdas. But I guess I don't understand what they mean regarding support for c++11 generally.
Are we talking about significant rewrites and with what compiler? I don't see vendors reaching compliance for at least a year.
The new syntax would not as type safety is being enforced at compile time. However the old syntax using strings is also available so if it is, then yes used the same preprocessor macro step will apply.
Was reading to find answers to some of my own questions and found this link helpful regarding use of c++11 in Qt5 [0]. Use of c++11 features seems limited in the first release which makes sense.
You know why this is? Because there is no correct pronunciation in English for two consecutive consonants. Similarly, SQL is not pronounced "sequel", because it contains no vowels. TeX is not pronounced "teck" because there no letter chi in the Roman alphabet.
All these cutesy insider pronunciations only serve to confuse and alienate the uninitiated, it's elitist nonsense.
Or if you deal in it every day, saying sequel comes more natural than saying ess cue ell. There's a lot more legitimately confusing things in the world of IT than pronunciation of commonly used names.
I don't fight my colleagues when they say "Suss" rather than the correct pronunciation of Suse Linux, because when it comes down to it, language is just an agreement that certain sounds mean something to the group that they are being spoken to. There's nothing inherent about the sanctity of language. If you can't be flexible, you might not be cut out for it.
SQL is pronounced 'sequel' not because it's cute, but because that's what it was originally called by IBM, and was changed only due to a conflicting trademark. The then-current DBA's never stopped calling it 'sequel' and the pronunciation stuck.
I pronounced SQL by saying each letter for a long time, as I'd learnt all about it online and never spoken to anyone about it. It didn't help that I often worked with MSSQL, or... Messequel?
It's "cute", because she is or, more importantly, because the Trolls thought she was. She was "cute" before the Trolls sold her to Nokia; I think she still is.
I was doing Qt development in the 3.0-4.0 timeframe (3.x was release, 4.0 was in beta) back in 2004/2005 when Trolltech was independent and I attended a Trolltech sponsored conference at which all the "Trolls" called it "Cute". You can't pin this one on Nokia.
FWIW, despite knowing the "real" pronunciation, I refuse to call it anything other than Q-T ("Cue-tee") aloud
It's licensed under LGPL 2.1 (or GPL3 if you prefer), so it's free for proprietary/closed-source usage as long as you don't modify Qt itself, or if you at least distribute the source code of the modified Qt binaries. There is also a commercial license if you want support or to be able to modify Qt for a closed-source project, but that requires direct contact with their sales folks afaik.
