4 ms·

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 th

by bergie 14y ago

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.

daliusd 14y ago
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-port-contributed-to-the-qt-project/ 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.
DennisP 14y ago
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.
- Scramblejams 14y ago
  Having experienced BeOS, I've always been bummed it didn't see wider success. Its UI responsiveness under heavy load has never been equaled.
  - vidarh 14y ago
    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.
    - ygra 14y ago
      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).
    - beagle3 14y ago
      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.
      - marshray 14y ago
        * Garbage collection * APIs blocking on network operations (e.g., gethostbyname()) How does BeOS avoid/avoid lagging with these things?
        timv 14y ago
        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.
  - ksherlock 14y ago
    Palm bought up Be's employees and assets.
    - atdrummond 14y ago
      Yes but it was part of PalmSource, not palmOne. So Be Inc.'s assets are held by ACCESS, rather than HP.
      - daeken 14y ago
        I've always dreamed of buying back Be's assets from ACCESS. One day I'll be able to.

by bergie 14y ago

daliusd 14y ago

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-port-contributed-to-the-qt-project/ 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.

DennisP 14y ago

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.

Scramblejams 14y ago
Having experienced BeOS, I've always been bummed it didn't see wider success. Its UI responsiveness under heavy load has never been equaled.
- vidarh 14y ago
  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.
  - ygra 14y ago
    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).
  - beagle3 14y ago
    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.
    - marshray 14y ago
      * Garbage collection * APIs blocking on network operations (e.g., gethostbyname()) How does BeOS avoid/avoid lagging with these things?
      - timv 14y ago
        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.
- ksherlock 14y ago
  Palm bought up Be's employees and assets.
  - atdrummond 14y ago
    Yes but it was part of PalmSource, not palmOne. So Be Inc.'s assets are held by ACCESS, rather than HP.
    - daeken 14y ago
      I've always dreamed of buying back Be's assets from ACCESS. One day I'll be able to.