[haiku-development] Re: QT for R2
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 21 Mar 2012 19:40:58 +0100
On Mon, Mar 19, 2012 at 11:12:17PM +0200, Rimas Kudelis wrote:
> One could as well ask, what is the benefit of (not so) Be API over
> Qt? I think these are the questions that the investigation of the
> feasability of replacing partly or completely the Be API with QT
> would answer. You could as well ask, what is the benefit of FreeBSD
> over Linux, if both run same applications, but both have been
> coexisting for years somehow...
As far as I can tell, the Be API is lacking mostly in the UI area and
has some design problems in the upper layers, the ones most visible to
application developers. On the other hand, it is also a Kernel API,
and handles inter-application things, two things that Qt is (so far)
unable to do.
So, the question is, which way is more interesting : adding the lower
level to Qt, or replacing/refreshing the higher level of the Be API ?
With all the work involved in recreating the BeAPI dring Haiku life, I
find it strange that some people are willing to drop it and replace it.
I've learnt that sometimes you have to admit that your work is not good
and you just have to throw it away and start over; but I don't see how
it's the case for the Be API. Maybe I just need some more practise of
it.
>
> >Am I alone in thinking this is a big mistake?
>
> Certainly not, but I think you'd agree that without real and
> thorough comparison, these are just emotions showing through. You
> could as well ask why use ICU instead of developing a Haiku-only
> internationalization library, or why use BSD network drivers instead
> of writing our own, etc etc. In the end, what matters to the user is
> how the OS and application works, not what toolkit was used to make
> that application. And if Qt was native and integrated into Haiku, I
> think this would already make it somewhat advantageous over Linux
> and *BSD where it is a just another toolkit.
True, the question is actually how much work is involved in that "if",
versus working on our own API to make it better.
As you mention it, several time in the past the choice went for an
existing solution, but, in some other cases it didn't. The package
manager is an example of this, and there are many others (Media Player
while we could have VLC, ...). It's a choice to be made case by case,
depending on if the existing solution is good enough.
>
> Disclaimer: I'm not a (Haiku) programmer and I have no idea which
> toolkit is better. But I believe that a toolkit is just means to
> achieve the goal, not the goal itself. And if Qt would bring Haiku
> closer to production state, while not diverting it from its initial
> goals of being lightweight, fast and simple, then why resist?
The toolkit is also part of BeOS/Haiku identity for (some) developers,
hence the emotional reactions in this discussion. Also, this is an R2
discussion, and we have a big problem with that, as the project goal for
Haiku is "recreating BeOS R5", and this is as well the goal for R1. The
result is that anything post-R1 stays blurry, and no one want to loo kat
it, by fear of what could happen. There are many ways the Haiku project
could go after R1, let's hope we manage to select only one and not fork
dozens of versions.
--
Adrien.
Other related posts:
