[haiku-development] Re: R1/a4 initial planning
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 24 Feb 2012 14:28:07 +0100
On 2012-02-24 at 10:44:42 [+0100], Julian Harnath
<julian.harnath@xxxxxxxxxxxxxx> wrote:
> 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.
Don't forget that Qt does have an event system which isn't too different
from Haiku's messaging. A thread with an event loop is similar to BLooper
and QObject to BHandler. The main difference is that Qt events are typed
objects while BMessages are generic containers. Though actually nothing
prevents you (or us) from creating an event class that provides a generic
container. That would probably also be a good basis for inter-app messaging.
> 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?
No clue, I haven't really looked at it yet.
> 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.
Let's be honest here. First of all those applications likely wouldn't even
exist on Haiku otherwise (or just as regular ports as they are now).
Secondly, that's mainly about how lazy a porter is. For a good port one has
to go the extra mile and do some #ifdef'ed platform specific coding. The
difference to the status quo is that now you have to #ifdef the whole
interface. IOW porting gets easier, it isn't necessarily going to be for
free in all cases (at least not good porting).
> > 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.
Yep, that's the tradeoff: You get development for free, but lose your full
control over it.
CU, Ingo
Other related posts:
