[haiku-development] Re: R1/a4 initial planning
- From: Ryan Leavengood <leavengood@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 22 Feb 2012 21:46:11 -0500
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. 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.
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."
To further push "delicacy", at what point does Haiku just become pointless?
--
Regards,
Ryan
Other related posts:
