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.
Permalink for comment 391393
To read all comments associated with this story, please click here.
I hope not. Haiku has it's own UI and doesn't need KDE or another desktop environment. And Haiku has a nice coding team vith a good vision. I don't want Haiku to became like Linux with 10000 distribution, 10000 desktops, 10000 window managers, 10000 libs that does the same thing.
First of all, I'm not aware of any technical reasons why the Haiku applications using the port of Qt4 should - once it's completed - behave more alien than the geniune article. In the end, Qt can be considered a rather thin abstraction layer above the native GUI, input server, etc. . Sure, it will be interesting to see how good phonon, solid et al. will be able to abstract away the corresponding interfaces given that Haiku is a somewhat different beast than your typical *nix plattform, and there is also always the problem of developers having to adhere to - sometimes contradictory - HIG and look&feel conventions, but this is nothing that can't be overcome by a dedicated and knowledgeable team of developers. Moreover, taking the "haiku native, or bust" line of argumentation to it's conclusion, all efforts to port GTK+, wxWidgets, and - heaven forbid - Java would also have to stop.
Furthermore, you can run KDE or Qt applications nicely on top of Windows (and increasingly ReactOs too), without having to drag concepts foreign to the hosting platforms like custom window managers or "desktop environments" along. And while I applaud the haiku devs for their efforts and try to defend them whenever Linux or *BSD users question the prospects of having another alternative OS, they will have a hard time winning me over as an user, if I'm not able to either take my working environment with me (and that consists atm of mainly KDE4 and Qt applications) or if they at least provide an adequat replacement for all those apps that I - and other potential contributors, because, let's face it, this is what Haiku needs in order to sustain organic growth - need.
I don't see a native replacement for Kate/KDevelop (or code::blocks, etc.) on the horizon. I'm also not aware of viable native alternatives to vlc, scribus, koffice, digikam, amarok, marble, kile, kdenlive etc. . At the risk of triggering another puritist vs. pragmatist discussion, but isn't it better to allow potential developers and contributors to use cross-plattform applications (esp. if they are - in the case of KDE4 and most Qt applications - written with cross-plattformness in mind from the very beginning) than to have them leave for greener pastures (or never come to your corner of the FLOSS playground, for that matter). Furthermore, even if native applications start to address these needs, not sharing code in the form of yet-another-1000-libraries-that-all-do-the-same with existing projects like for example koffice, akonadi, etc. would be pretty stupid given that developer time and coffeine are the two most scare ressources in FLOSS development.
Lastly, as a developer using Qt for most of my work, Haiku would become a lot more attrictive as a target plattform at once. It would also be a lot easier convincing the head of our department considering Haiku as an plattform for our embedded computers if the support of this additional plattform could be done with very little additional costs and manpower (provided that the Qt port is kept up to date and is fairly complete. Having KDE recognise Haiku as an official target plattform would help on both of this goals, btw.).
Member since:
2007-11-17
First of all, I'm not aware of any technical reasons why the Haiku applications using the port of Qt4 should - once it's completed - behave more alien than the geniune article. In the end, Qt can be considered a rather thin abstraction layer above the native GUI, input server, etc. . Sure, it will be interesting to see how good phonon, solid et al. will be able to abstract away the corresponding interfaces given that Haiku is a somewhat different beast than your typical *nix plattform, and there is also always the problem of developers having to adhere to - sometimes contradictory - HIG and look&feel conventions, but this is nothing that can't be overcome by a dedicated and knowledgeable team of developers. Moreover, taking the "haiku native, or bust" line of argumentation to it's conclusion, all efforts to port GTK+, wxWidgets, and - heaven forbid - Java would also have to stop.
Furthermore, you can run KDE or Qt applications nicely on top of Windows (and increasingly ReactOs too), without having to drag concepts foreign to the hosting platforms like custom window managers or "desktop environments" along. And while I applaud the haiku devs for their efforts and try to defend them whenever Linux or *BSD users question the prospects of having another alternative OS, they will have a hard time winning me over as an user, if I'm not able to either take my working environment with me (and that consists atm of mainly KDE4 and Qt applications) or if they at least provide an adequat replacement for all those apps that I - and other potential contributors, because, let's face it, this is what Haiku needs in order to sustain organic growth - need.
I don't see a native replacement for Kate/KDevelop (or code::blocks, etc.) on the horizon. I'm also not aware of viable native alternatives to vlc, scribus, koffice, digikam, amarok, marble, kile, kdenlive etc. . At the risk of triggering another puritist vs. pragmatist discussion, but isn't it better to allow potential developers and contributors to use cross-plattform applications (esp. if they are - in the case of KDE4 and most Qt applications - written with cross-plattformness in mind from the very beginning) than to have them leave for greener pastures (or never come to your corner of the FLOSS playground, for that matter). Furthermore, even if native applications start to address these needs, not sharing code in the form of yet-another-1000-libraries-that-all-do-the-same with existing projects like for example koffice, akonadi, etc. would be pretty stupid given that developer time and coffeine are the two most scare ressources in FLOSS development.
Lastly, as a developer using Qt for most of my work, Haiku would become a lot more attrictive as a target plattform at once. It would also be a lot easier convincing the head of our department considering Haiku as an plattform for our embedded computers if the support of this additional plattform could be done with very little additional costs and manpower (provided that the Qt port is kept up to date and is fairly complete. Having KDE recognise Haiku as an official target plattform would help on both of this goals, btw.).