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

  • From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 29 Mar 2009 22:49:46 +0200

2009/3/29 Stephan Assmus <superstippi@xxxxxx>:
>
> On 2009-03-29 at 09:00:33 [+0200], Jorge G. Mare <koki@xxxxxxxxxxxxx> wrote:
>> Matt Madia wrote:
>> > On Sat, Mar 28, 2009 at 4:34 PM, Jorge G. Mare <koki@xxxxxxxxxxxxx>
>> > wrote:
>> >
>> > > Focus shift?
>> >
>> > I wouldn't call this a focus shift at all.
>>
>> There is a clear contradiction between what Ingo asserted in his email
>> and some of the things that the project has been saying all along as a
>> way to differentiate itself from other open source OSes (mostly Linux).
>>
>> If this is not a fundamental shift in Haiku's philosophy, then how do you
>> reconcile the assertion "that having at least one or two of the major
>> toolkits available on Haiku is simply a necessity" (quote from Ingo) with
>> what the project has been saying all along about Haiku being "developed
>> under a single unified vision for the whole OS", that "includes a
>> graphical user interface tightly tied to a unique graphics system" and
>> that does not rely on "toolkits such as GTK+ or Qt" (quotes from the
>> Haiku website FAQ)?
>
> I can see two sides to this.
>
> 1) Thoughts about and attempts at porting Qt are nothing new. In fact, Ingo
> has been part of one of the porting efforts (to BeOS) years ago. I don't
> regard it any different than trying to port OpenJDK. That's exactly the
> same thing, because Java is not only another programming language, it's
> also a tool kit. It has the very same need about being properly integrated,
> or Java apps won't feel native at all. But noone said "No, please don't
> port Java!".
> 2) The desire to port a major tool kit (Qt in particular) and make it's API
> available as a first class citicen along side the Be API has grown stronger
> and stronger in me because a) it's beautifully designed and is just as nice
> or nicer as the Be API, and much, much more complete. And b) we need to
> catch up, or we will always remain in this "has great potential" state but
> in reality we will only grow a bigger gap to the other platforms over time.

I think this discussion is missing a third option.

* Caution: flamable material ahead *

This option is to use the Qt API as the core Haiku API. This means
side-tracking the BeOS API as a legacy API, and rewriting the kernel
and the app_server in such a way that it supports Qt as a native API.

Now if this idea is ever viable for discussion (which I doubt it will
when I view this thread), it will obviously invoke a lot of emotional
responses. Many of the arguments will boil down to taste, for example
in this thread Axel severely disliking Qt's use of moc and signals and
slots. Or about doing away with BeOS concepts such as messages (at
least in the GUI programming).

[to throw in an opinion: I feel that the message system is extremely
powerful, however, due to the strong-typed nature of C++, it will
always be a ... nuisance to add and extract data from messages. Most
of it can be replaced with signals and slots, and some things can be
worked around]

More practical points of discussion would be about the role and power
of Qt Software (and eventually Nokia) on Haiku, or how Haiku
applications can distinguish themselves from 'generic' Qt
applications.

Anyway, in no way does this idea reflect my personal stand on the
matter. I just wanted to make it clear that there is another level on
which to discuss what is native and what not. Especially since this
thread is also on what is smart in a business sense.

Kind regards,

Niels

Other related posts:

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