[haiku-development] Re: R1/a4 initial planning
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 23 Feb 2012 06:00:47 +0100
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:
