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

Ryan Leavengood wrote:
> On Wed, Feb 22, 2012 at 7:28 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > Since I started poking "delicate" matters already, I guess I can throw in my
> > opinion about Qt and Haiku's native API. I think we should consider Qt as
> > base of the Haiku R2 API, replacing most of the Be/Haiku C++ API. Haiku
> > specific extensions (like support for extended attributes) could be
> > implemented on top of it or directly in the standard Qt classes.
> 
> It isn't a terrible idea really. I have not extensively look at Qt or
> programmed with it but from what I know it is pretty good.
> 
> I guess the question is whether the signals and slots system can work
> with the very threaded Haiku GUI system. My understanding is that
> signals and slots is not very thread-safe.

The mechanism itself is thread-aware. Each object belongs to a thread and a 
thread can run an event loop (making it somewhat similar to a BLooper). Unless 
one explicitly requests a direct connection, a signal is handled in the thread 
of the receiving object.

> I'm pretty sure we don't
> want to throw away Haiku's highly threaded design, since at this point
> that is one of the true selling points of Haiku in our current
> multi-core dominated world.

The GUI in Qt is single-thread (GUI classes must live in the main thread). I've 
heard this is less a restriction of Qt itself than one of a certain platform. 
So this may or may not be something one can fiddle with. I don't find it that 
important, though. The rule to move tasks that can take time to a separate 
thread should be followed anyway. That leaves the regular event handling and 
drawing which won't challenge today's processors.

> Plus there is the nostalgia of the BeOS API, and even the sense of
> "branding" in Haiku having its own API. If Haiku becomes just another
> Qt platform it might be easier for people just to lump it in as "yet
> another Linux."

I find sticking to our own API just to have a marketing bullet point not a 
sufficient reason for doing it. Particularly when the alternative is better.

> To further push "delicacy", at what point does Haiku just become pointless?

That's a good question. In fact all the BeOS buzzwords (file system with 
queryable metadata, media OS, pervasive multithreading, well-designed C++ API) 
either don't truly apply anymore (because some other OS does it better/at least 
as good) or have become meaningless. I think a niche for Haiku is to be a 
well-integrated open source OS that doesn't get in the user's way.

CU, Ingo

Other related posts: