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

  • From: "Jorge G. Mare" <koki@xxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 30 Mar 2009 09:44:31 -0700

Hi Stippi,

Before I reply (and I get into more trouble :) ) I want to say that this
is all in IMHO and FWIW, and nothing of what I say is meant to offend or
disrespect anyone, particularly not the core devs (such as Ingo) for
whom I have a lot of respect and admiration for their dedication to the
project over the years. :)

Stephan Assmus wrote:
> 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.
>   

Maybe it is just out of ignorance, but (with one obvious exception) I
don't see Java as a language that is being used pervasively for desktop
apps as Qt. I see Java more in the realm of web apps, where the
influence that it can leverage over the desktop user experience is
rather limited. In contrast, Qt desktop apps, are quite pervasive.
Again, maybe I am just too ignorant. :)

> 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.
>   

If you want the BeAPI to be adopted and to evolve in the future (I would
think that is the whole idea of starting Haiku in the first place),
offering Qt as an alternative will not serve as an incentive to that
end; in fact, I am pretty sure it will have a totally opposite effect. I
think David McPaul's analogy with regards to media playing in Haiku is
very valid; so, yes, VLC is a great app, but it has also ingrained the
notion that if you can't play a file in the native MediaPlayer you can
just use VLC instead; so users don't care to report problems and as a
result Haiku's media playing capabilities don't improve. That's is
definitely not what we want, is it?

That does not mean that Haiku should or even could say "no" to toolkit
ports (they will come, as you say). But I don't think it is conducive to
the project's goals as originally defined to embrace the idea of doing a
well integrated port within the realm of Haiku and using resources to
that end. That will not encourage new devs to use the Haiku API, nor
will it very inducing to working on improving the native API in the
future. The "alternative" API will probably become the API that people
will use most, and the Haiku API will then probably be relegated to a
few diehards. If that happens, what is the whole point then? :)

Of course the Haiku API is not perfect, and as it evolves, there are
probably things that can be learned from other toolkits (there always
are). If Qt (or any other toolkit, for that matter) has things that
Haiku can benefit from, then incorporating if not the code but the
concepts/designs would obviously be a good thing. But it would still be
the Haiku API.

Some have pointed out that I misread Ingo's email (sorry that I don't
respond individually; too many messages to even catchup). But to me, the
way he worded the message did not sound like "it would be nice to have"
at all. Had this message been from a Qt fanboy (no offense intended,
just trying to make a point here), then one could disregard the it. But
the the fact that it comes from probably the most influential core
developer of the project, gives it a totally different meaning.

I share everyone's desire to get as many apps as possible running in
Haiku, but I think we should all be patient and realistic; this does not
happen overnight. Haiku has been in development for almost 8 years now,
and it is at a pre-alpha stage. An ecosystem around the project is
definitely forming, but you have to let it run its course, and that
takes time (many years, as we already know). Trying to take a shortcut
will make the whole idea of creating an OS like Haiku a moot one IMHO.

A good thing to do would be to think on how to develop incentives for
new devs to embrace the Haiku API and create apps that take advantage of
the unique qualities of the OS. Perhaps some sort of application contest
with rewards (to replace the HCD?) could work. Education is also
important; I don't think the benefits of Haiku are well understood, so
perhaps live presentations to introduce new people to the API/etc. would
be something beneficial. Of course, all of this takes time and effort
but, hey, that *is* the bottom line: no pain, no gain. :)

Regards,

Jorge

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 03-2009