[haiku-development] Re: R1/a4 initial planning

Ingo Weinhold <ingo_weinhold@xxxxxx> schrieb:

> You're the third or fourth person to suggest that the Be/Haiku API is 
> great while Qt sucks without giving any specifics. So what are, in your 
opinion, the parts of the Haiku API that Qt can't compete with?

Personally, I prefer messaging-based approaches over the signal/slot of 
Qt because it is more flexible, but that's probably just a matter of 
taste. What about things like MediaKit, MidiKit, GameKit? Yes, there's 
Phonon etc (which I don't know much about, most of my Qt experience was 
long ago, before Phonon existed). Is Phonon good enough for complex 
low-latency audio/video applications? Yeah, a "MediaKit 2.0" could be 
written as Qt-extension, but would it become an official part of Qt? If 
not, using the "MediaKit 2.0" instead of Phonon ruins portability 
again, so everyone who wants to have their application also on 
Linux/Windows/MacOS would end up not using the MediaKit and just go 
with Phonon instead. I'd expect most applications would go for the 
lowest common demoninator.
How about filesystem attributes? I really like how they are used in 
BeOS/Haiku, which is still unique as far as I know. The influx of Qt-
ported apps would never use them, and even applications written for 
Haiku with the intent of porting to another OS (for commercial sales or 
whatever) could not use them in the same way (or would need another 
layer of indirection). Again a case for lowest common denominator.

> AFAIK Haiku would remain unique, since there isn't any other OS with 
> Qt as the primary API.

Yes, but Haiku would also give up its autonomy on API decisions. 
Wherever Qt goes, Haiku will have to follow.. except Haiku would want 
to fork Qt. So if Qt one day decides to go into a direction which 
contradicts Haiku's design ideas, Haiku would have to adapt or fork.

Regards,
Julian

Other related posts: