[haiku-development] Re: GSOC 2013 QT in R2
- From: M RICE <rice43@xxxxxxxxxxxxxx>
- To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
- Date: Wed, 19 Jun 2013 23:58:08 +0100 (BST)
Hey,
I am a newbie in Haiku and browsed through the Haiku Website. There I saw this
Idea of Google Summer of Code. I must say I don't like this Idea because QT
doesn't use the threading effectiveness and flexibility of the Beos/Haiku API
(as far as I am concerned). I think haiku should fork QT, rename everthing,
remove portability and make it use of extensive threading, Then I would take it
as new native API.
My suggestions are probably not the right but I think this should be discussed
before making haiku with the old beos API incomaptible.
Greetings,
Mariusz Wojcik
__________________________________________________________
Hello,
Whilst I believe QT is great, i don't think your idea really holds any water.
You see, one of the great things about QT (and any cross-platform widget
toolkit) is the fact that it is so multi-platform. Forking it, stripping it,
and renaming anything will not give Haiku any advantages, and completely break
all support for existing QT apps (of which , as Clemens pointed out, many run
already on Haiku through the existing QT port). Of course, that's not even
mentioning the work that would need to be done just to fork and rename
everything.
All in all, it seems to me like a pointless waste of time, compared to just
depreciating the BeOS API and adopting plain ol' QT. Also, in many situations,
the BeOS API is perfectly fine. Sure, it could do with updating and modernising
in places, but isn't that what an API/ABI compatible "clone" of BeOS is there
to do, right?
Other related posts:
