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.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-10-17
Haiku has never been about being multiplatform or supporting multiple toolkits. This notion frontally contradicts a lot that Haiku has stood for from the very beginning: a compact, lean and mean system, consistent throughout by means of a single API that is both clean and complete (please, read the general FAQ on the Haiku website). This position is in clear contrast with the more complex landscape of mutiple toolkits, DEs, multiple layers of abstraction, etc. that, IMVHO, perpetuate the complexity of Linux on the desktop.
In this context, opening the gate to multiple toolkits would be taking the Linux road, and would signal the beginning of the end of Haiku how it was originally thought out to be. It will also most likely make the native API irrelevant, as nobody will care to use it in the end.
When/if that happens, Haiku is not compelling anymore, and it would become hard to find a valid reason why anyone would want to run in Haiku apps that already run, are more up-to-date and better supported than on Linux; such a scenario would only make Haiku another uninteresting "me too" OS.
Haiku can only become compelling if it has something fundamentally different and better to offer, and offering the very same user space stuff as other more mature platforms will not cut it. Only through native apps that take advantage and expose the unique qualities of the OS (multi-threadedness, extended attributes, data translators, media kit, etc. etc.) to the end user can take you there, even if it takes many more years (which it will).
I do understand the logic behind the desire for something like Qt, but I think it is being driven by an understandable but short-sighted impatience to have more apps in the short term than to stick to the project's original long term vision to develop Haiku into the unique platform that it was set out to be in the first place.
Member since:2007-01-22
Member since:2007-11-17
First of all, I would like to say that the geek in me sympathises a lot with what you say in your comment.
With that being said, how can people who see this as a problem prevent such things? Because, and I'm extrapolating here from the comments on this thread and my personal opinion, a lot of people seem to find the prospect of running non-native Haiku applications ontop of an interesting alternative Os like Haiku pretty attractive by itself. It may not be what you or even the core developers envisioned, but since the operating system is licensed under a permissive FLOSS license, people will start to do what they always have done if they have the possibility and means to do it: They will start to tinker and come up with crazy and sometimes even scary ideas.
The problems and inconsistencies you describe are imho not specific to Linux (although the Linux family of OSes is a good subject to study these effects) but are to varying extents part of the whole software development process. If a foo does not provide means to achieve bar and if bar is even remotely related to foo and important/interesting enough for a sufficiant number of participants in the ecosystem, either foo-bar will be developed or somebody will start/port an alternative to foo. The cathedral method tends to stop working once you open the bazaar.
Short of trying to keep the "official" Haiku distro as close to the "vision" as possible and ignoring everything else that happens in this space (which would likely increase the number of distros around, if Haiku by itself is viable enough to generate interest beyond the spheres of BeOS enthusiasts) or trying to make Haiku so cumbersome to work with that nobody even thinks about developing / porting applications for it (which would be a tad counterproductive and does not always work as expected, cf. Symbian :-) ), I'm afrait that I see no way to prevent a scenario where Haiku can be used in ways not desired by the enthusiasts.
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.).