[haiku-development] Re: R1/a4 initial planning
- From: "Jürgen Wall" <x-otic@xxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 23 Feb 2012 08:39:50 +0100
> > 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.
> >
> > There are a whole bunch of reasons for such a move. The most important
> one is
> > that parts of the current API (particularly the interface kit) are
> > incomplete, have a rather poor design and thus need to be replaced, and
> we
> > simply don't have the manpower to do that. Qt certainly isn't perfect
> either,
> > but it is way more complete and IMO has a significantly better design
> wrt.
> > GUI classes. And on top of this it is actively maintained.
> >
> > The good integration of the port and its Haiku specific extensions would
> > still allow Haiku applications to be as native and integrated as they
> are
> > when using the current API. Ported Qt applications would automatically
> > benefit in that respect already and could be improved even more by
> making
> > conditional use of Haiku extensions. Moreover native Haiku applications
> > suddenly become easily portable.
>
> I have to say that I quite like this idea. I haven't looked too much
> into Qt, but they have some really neat technologies that we could
> benefit from. I think that with this approach we could stay true to
> the vision of Haiku as a unified platform, while decreasing the
> development burden, letting us focus on developing the features that
> make Haiku unique and awesome! Qt isn't the only path, but as I see
> it, it's one that could greatly accelerate Haiku's development, while
> benefiting end users and developers alike, which is certainly a
> worthwhile goal.
>
> --Alex
I find this idea very alluring too!
Just to throw in an idea, wouldn't it make sense to have someone analyze the
requirements and efforts of such an API transition in a CSoC task?
This task would enclose analysis of the Haiku API and the QT API
delivering a rough plan how to map/adapt/replace parts.
It'd be kind of an applicability research task.
Regards,
Juergen
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Other related posts: