[haiku-development] Re: R1/a4 initial planning

On 2012-02-22 at 07:21:48 [+0100], Ryan Leavengood <leavengood@xxxxxxxxx> 
wrote:
> On Tue, Feb 21, 2012 at 8:03 PM, Sean Collins <smc.collins@xxxxxxxxxxx> 
> wrote:
> > then maybe the best alternative, is to resort to QTwebkit, or another
> > webkit browser like Chrome etc, if your saying its going to take years to
> > finish and make presentable.At some point the users donating the $$ are
> > going to want to see some tangible gains for that investment. A offhanded
> > comment was recently made and this fustration is driven by a apparent lack
> > of progress from the outside pov. There are other options, though they are
> > not everyones favorite, if developer time is truely this scarce, then 
> > maybe
> > something this big, should be a port and not a native project.
> 
> Well really because Haiku is its own unique system anything requires
> some porting. To make use of QtWebKit we need a good QT port for
> Haiku. Then it becomes a question of putting the development time into
> QT which might better be spent on the native Haiku API or on our
> native WebKit port. And mostly you don't know beforehand which is the
> better approach. But we tend to be biased toward the Haiku native side
> since, well, why else would we be writing our own OS? ;)

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.

CU, Ingo

Other related posts: