Linked by Thom Holwerda on Tue 27th Oct 2009 11:02 UTC
Qt 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 391325
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Sad but true!
by Polari on Tue 27th Oct 2009 11:45 UTC in reply to "Sad but true!"
Polari
Member since:
2006-02-24

The Webkit port is in development, but it's a big project. I don't see how this is at all related to your Mockup project. Seeing as Haiku is still in heavy development and some way away from a stable release, Firefox 2.x and Arora will make do for the time being.

Anyway, this is fantastic news. Hopefully KOffice makes it over soon as this is an area in which Haiku is sorely lacking and there is no other quick fix for. Amarok would be nice as well. Obviously native applications would be preferable this is a good, practical solution to one of Haiku's biggest problems. It should allow for an updated VLC port too.

Reply Parent Score: 9

RE[2]: Sad but true!
by plfiorini on Tue 27th Oct 2009 12:02 in reply to "RE: Sad but true!"
plfiorini 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.

Reply Parent Score: 2

RE[3]: Sad but true!
by Laurence on Tue 27th Oct 2009 12:43 in reply to "RE[2]: Sad but true!"
Laurence 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?


The point being that there's more to an OS than just it's graphics toolkit

Reply Parent Score: 6

RE[3]: Sad but true!
by silix on Tue 27th Oct 2009 14:04 in reply to "RE[2]: Sad but true!"
silix 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

Reply Parent Score: 3

RE[3]: Sad but true!
by fithisux on Wed 28th Oct 2009 08:18 in reply to "RE[2]: Sad but true!"
fithisux Member since:
2006-01-22

"What is the point of using Haiku"

1. The windowing system
2. The focus on the desktop at the HW level

possibly later

3. The use of true uKernel unlike MacOSX.

Reply Parent Score: 2