[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)

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.

Mariusz Wojcik



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 

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: