[haiku-development] Re: Haiku, Qt and apps, oh my!

  • From: André Braga <meianoite@xxxxxxxxx>
  • To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
  • Date: Mon, 30 Mar 2009 03:19:13 -0300

Em 29/03/2009, às 17:49, Niels Reedijk <niels.reedijk@xxxxxxxxx> escreveu:

I think this discussion is missing a third option. [...] This option is to use the Qt API as the core Haiku API. This means side-tracking the BeOS API as a legacy API, and rewriting the kernel and the app_server in such a way that it supports Qt as a native API. 

There is a fourth option that I'm truly surprised no one brought up yet.
Much of this discussion have centered around the relevance of Haiku as a platform as it competes with Windows, Mac OS, and X11-based OSs in general.
Well, the 4th option would then be fixing the shortcomings of the Be API for R2 (that's a given), and model additional APIs and kits after the good stuff found on Qt. And then surpass it. Not in featur...itis, but in *brilliance*.
It would then be quite possible to, instead of porting Qt, have wrappers mapping popular Qt classes into HR2 ones, which essentially has the effect of removing Qt's platform abstraction layer as much as possible. The rest of Qt which wouldn't make sense to have a correspondence in the native API could be ported with considerable ease, then. 

This would:
1) bring the native API up to at the very least feature parity regarding what's expected from a contemporary toolkit; 
2) provide a powerful tool to facilitate porting existing software;
3) enable a rather large community of developers to become almost immediately proficent with the *native* API, since it would feel quite familiar to what they're used to (IOW, the semantic gap between the APIs would be narrow enough that developers skilled in one API would quickly become productive with the other); 4) by (3), having a good platform as a basis (and by that I mean the very responsive UI; the great file system; innovative app coordination via replicants, the scripting interface, translators and so on), coupled with an API that feels familiar but stands on its own feet, will make Haiku quite an attractive platform to develop *native* software for.
One could argue that this didn't work at all for GNUStep; well, sure, but the thing is, Cocoa is well beyond GNUStep. To target both you must shoot for the lowest common denominator (which would be the latter) and lose a *ton* of attractive stuff that Apple adds at each OS version.
For this to work as I envision, Qt has to be the lowest common denominator, and the native API and platform as a whole has to keep innovating and offer a bunch of cool stuff. We have to invert the current status in this game of catch-up. 

Qt would be just the bridge to bring manpower over to our side.

Developers must *lust* after Haiku, nothing less.


Cheers,
A.

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 03-2009