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.

Having experienced BeOS, I've always been bummed it didn't see wider success. Its UI responsiveness under heavy load has never been equaled.

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.

* Garbage collection

* APIs blocking on network operations (e.g., gethostbyname())

How does BeOS avoid/avoid lagging with these things?

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).

Palm bought up Be's employees and assets.

Yes but it was part of PalmSource, not palmOne. So Be Inc.'s assets are held by ACCESS, rather than HP.

I've always dreamed of buying back Be's assets from ACCESS. One day I'll be able to.