Linked by Thom Holwerda on Tue 27th Oct 2009 11:02 UTC
The Haiku alpha is barely out the door, and we already have another important news item about the open source reimplementation of the BeOS. About 18 months ago, Evgeny Abdraimov started porting the Qt4 graphical toolkit to Haiku, and now, we ave some seriously epic screenshots showing a multitude of Qt4 applications running in Haiku, as well as a developer preview release.
Thread beginning with comment 391331
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2007-03-26
What I'm saying here is that we'll have to wait a lot of years to have the same quality and quantity on native Haiku apps.
In the meanwhile we'll end up using Qt4 apps just like we can do on Linux so what's the point on using Haiku?
In the meanwhile we'll end up using Qt4 apps just like we can do on Linux so what's the point on using Haiku?
The point being that there's more to an OS than just it's graphics toolkit
Member since:2006-01-01
Member since:2006-03-01
In the meanwhile we'll end up using Qt4 apps just like we can do on Linux so what's the point on using Haiku? 
maybe the fact that unlike linux (with the plethora of distributions based on it, sometimes even unable to run binary applications deployed for some-year-old versions of themselves) haiku is a unified desktop platform (which btw has binary compatibility with applications developed and deployed on the BeOS ten yars ago, as its goal)
maybe the fact that, unlike linux (which maintains generality at the cost of case - optimized functionality (*) in its attempt to be everything for all kinds of devices), haiku is born to be none other than a desktop OS - and then (besides facing the user with more simplicity and visual consistency), can be, and is being optimized for desktop usage, since assumptions can be made (even if these would mean implementing desktop specific mechanisms in the kernel (**))
(*): case in point, local message based IPC, implemented over plain sockets in a userspace daemon, while other OS's implement it as a kernel primitive and base the C-library 's sockets on it - or the scheduler, having to rely on heuristics to determine whether a process is interactive, or having no means at all to determine whether a process is running in the foreground or background - both things a desktop native OS "knows" explicitly, should developers choose to leverage this with scheduler optimizations
(**) an example of this is in the icons - stored as compact vector data straight in the inode metadata (saving both space and read passes) - not that such a feature can't be implemented on linux, but it would require much more than a kernel patch...
or, maybe the fact that, unlike linux (where inconsistencies are found at all layers) a unified AND desktop oriented platform like haiku has an inherent higher consistency, both internally and towards the user - and a higher chance of keeping that consistency with the addition of a second API alongside the native one (granted the former is correctly implemented and applications behave/feel -even more importantly than "look"- like native ones)
that is, maybe that for third party application developers (besides users) haiku proves a better QT platform than linux, all in all ...
Edited 2009-10-27 14:18 UTC
Member since:2008-12-26
(*): case in point, local message based IPC, implemented over plain sockets in a userspace daemon
As the only thing that matters is "which one is faster", are there benchmarks that show notable performance benefits for Haiku message based IPC vs. Unix Domain sockets?
(BTW, They are not plain TCP sockets on Linux/Posix either).
Member since:2006-01-22
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2005-06-30
What I'm saying here is that we'll have to wait a lot of years to have the same quality and quantity on native Haiku apps.
In the meanwhile we'll end up using Qt4 apps just like we can do on Linux so what's the point on using Haiku?
Qt4 port is fine indeed, for example if the patch will be included in the official tree Haiku will be an official supported platform and we could get some large multiplatform applications on our system.
On the other hands I seriously think that if people won't start working on native applications soon it will be a problem later.