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.
Permalink for comment 391361
To read all comments associated with this story, please click here.
RE[3]: qt, not native
by bornagainenguin on Tue 27th Oct 2009 13:43 UTC in reply to "RE[2]: qt, not native"
Member since:

moondevil asked...


As a developer I would not care about the BeOS frameworks if my application is QT based.

If all functionality that my application requires is provided by the framework is already there, why should I look elsewhere?

Personally (and I hope to no offense) I hope you don't care about Haiku if you are a QT based developer. I really don't think this is about you if you are already a happy KDE developer, this is about something else altogether. This is about the applications.

As much as I love my Ubuntu desktop I am aware that (thanks to the tireless efforts of Linus Torvalds to cut out developers like Con Kolivas) Linux is not intended to be a desktop operating system, it is intended for servers. Haiku on the other hand has always been intended as a desktop operating system from the start and has performance to match. What the porting over of QT does for us is provide Haiku with the necessary applications any desktop operating system needs to survive.

Thanks to the efforts of FOSS desktop application developers there will be no chicken and the egg issues on other free operating systems like there were in the past for Linux.

moondevil asked...
If you want to take advantage of what makes a certain platform unique, your application will be tied to that system. If on the other hand you want to make your application work everywhere, then you have the problem that your framework can only provide common features.

Which is why I consider these applications to be a stopgap measure. They will eventually be replaced by better applications written for the Haiku platform itself and as such they will perform better and work better than the ports do. The whole pervasive multithreading was always more than just being buzzword-compliant you know...

How can 'simple' ports of QT applications possibly stand up to Haiku applications written to be able to take full advantage of the possibilities Haiku offers?


Edited 2009-10-27 13:48 UTC

Reply Parent Score: 5