[haiku-development] Re: Haiku, Qt and apps, oh my!

On 2009-03-29 at 19:31:06 [+0200], Jorge G. Mare <koki@xxxxxxxxxxxxx> wrote:
> IMHO, all this will do is open the gate to multiple toolkits and this 
> will 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.
> 
> Why would anyone want to use Haiku for multiplatform apps? I can already 
> run those apps in Linux, where they are much better supported. Why would 
> one even want to wait for (or contribute to) Haiku if it embraces the 
> position that multiple toolkits are a necessity and multiplatform apps is 
> the way to go? Personally, I would find it hard to find a reason.
> 
> IMHO, Haiku can only be compelling if it has something different and 
> better to offer, even if that means that it will take many more years to 
> get there. If you want Haiku to have any relevance, then only native apps 
> that support the unique qualities of the OS (multi-threadedness, extended 
> attributes, data translators, media kit, etc. etc.) can eventually take 
> you there. Multiple toolkits and ported apps will simply make Haiku 
> another "me too" OS.
> 
> As I said, I do understand the reasoning behind the desire for something 
> like Qt. I also understand that developers need to make a living. But if 
> Haiku is to become a "me too" OS with little different to offer, then 
> answering the "why Haiku?" question becomes quite difficult, even to 
> oneself.

You definitely have a point. I am just curious, though, what made you "draw 
the line" (so to speak) here, and not already when the OpenJDK port was 
initiated? I may remember it wrong, but it seemed you even actively 
supported it. But it is 100% the same problem.

The thing is, the choice may be between these two evils: Is Haiku doomed 
because it's not catching up fast enough? Or is it doomed if we "take 
leaps" in application and feature support via something like a Qt port (for 
the reasons you pointed out)? Different people will weigh these problems 
differently.

Saying "no" to any effort to port a major tool kit will be a major 
challenge. It's simply doable by anyone with enough dedication and skill. 
You might say these ports will be done anyways (just look at that GTK 
screenshot (nice work, btw!)). So what is the smartest thing to do? Keep 
them out of the "original Haiku distribution" and thereby encourage 
development of native apps (at least by intention)? Or would that mean that 
most Haiku users would use Haiku via another distribution which includes 
these toolkits for convenience? Or should we try our best to make sure 
there is at least one really feature complete port (and "encouraged" 
toolkit for cross-platform development)? A toolkit who's API is like an 
alternative to using the Be API, but otherwise just as tightly integrated? 
Maybe it isn't going to be that nice. Axel already pointed out some things 
about Qt which aren't perfect. Would they improve over time? Are they 
really that bad and arn't there bad things about the Be API? Is it a 
problem that we have no real control over the Qt API? Maybe that last point 
alone will make sure that there will always remain the Be API. Anyways, 
just some food for thought.

Best regards,
-Stephan

Other related posts: