[haiku-development] Re: QT for R2

2012/4/27 Przemysław Pintal <premislaus1988@xxxxxxxxx>:
> I hope this never happens. 10 years you develop this API, and suddenly
> throw your work into the trash? If I wanted to use QT, then I would
> install the Linux. Haiku would have lost its originality,
> identification, innovation. It would be a Linux distribution with a
> different kernel and window manager.
>
> QT port for Haiku, did not cause a sudden increase the number
> applications, developers and users. Everyone I talked to and who
> convinced to Haiku. According to highlight Haiku differences.

One of the benefits of Haiku over something like Linux is that Haiku
has one API rather than dozens. This makes it a simpler OS to grasp
for the application developer, and it is also easier for the user who
doesn't have to download and install a new set of API libraries for
each application. Although I suppose package management could mitigate
this problem for the user to a certain extent, Linux demonstrates that
this doesn't completely mitigate the problem, and it does little good
for the application developer.

If Haiku goes with QT for R2 we'll have 2 APIs, the Be API and the QT
API. I'd much rather see an updated Be API which is backwards
compatible to a certain extent with the current API kind of like how
the Layout APIs extend the Interface Kit while simultaneously
coexisting with the non-layout aware parts. That way there remains a
single API for Haiku. Updating the existing API to use the new
features provided by C++11 will give us a lot.

For the parts of the API we'd rather not maintain backwards compatible
we can create an H version of a class that is incompatible with the B
version. For example HMenu would be an incompatible replacement for
BMenu. BMenu would still be there, and would still work in apps that
use it, but HMenu would be the new menu class for R2.

Another negative of QT is it's license. Currently most code in the
source tree is licensed MIT, QT on the other hand is licensed GPL (or
maybe LGPL). I'd prefer we stay with MIT for the API.

On the other hand QT is here now and is supported by a much larger
development community and is cross-platform which means that Haiku
will instantly gain access to a host of new applications. Furthermore
an updated Be API would need to be designed and implemented within the
limited developer resources we have at our disposal. So I can see the
reasoning behind the idea of adopting QT rather than updating the
current API.

While I am interested in this discussion and it's conclusions, it
seems more appropriate for the Glass Elevator list than the devel
list, perhaps it should be continued there instead.

John Scipione

Other related posts: