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

  • From: Pier Luigi Fiorini <pierluigi.fiorini@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 28 Mar 2009 10:15:25 +0100

Ryan Leavengood ha scritto:
On Fri, Mar 27, 2009 at 9:48 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
IMHO, Qt is a must-have. It's a pretty solid API -- definitely better than
some parts of the Be API (like my "favorite", the interface kit) -- and by
far more complete.

Well Qt has had 10 years to improve while the Be API we are recreating
has stood still (excluding Zeta of course, but we aren't recreating
Zeta.) There are no doubts aspects of the interface kit leave a bit to
be desired, like the BMenu implementation.

I've never used KDE (the biggest Qt-based system I know of) for any
length of time and generally have not used Qt applications as far as I
know, so I am not too invested in it. From what I have seen it is a
decent toolkit though. I know the Qt layout API played a big part
influencing the Haiku layout API.
Qt is not good only at layouts. It has object oriented APIs for about everything and it seems they are taking attention to threads lately. There are also the Qt solutions I was looking yesterday at work, it's a very good platform and I just felt in love with their QtCreator. It's my favourite framework on both Windows and Linux, and I definitely think its API can influence a lot of Haiku kits.

Obviously, Haiku will be better though ;-)
I have no illusions that the "tiding us over" with ports is a temporary state
only. I believe that having at least one or two of the major toolkits
available on Haiku is simply a necessity.

It is not like we can stop people from porting software to Haiku. I
just think most people who want to use Haiku will prefer native apps
that (hopefully and eventually) will have things that set them apart
and provide more reasons to use Haiku itself. If Qt can be ported in a
way that apps look and act very native, maybe it isn't so bad. But it
seems as a multi-platform toolkit that there is certain things Qt must
leave out. If special platform specific code has to be written in a Qt
app to add something nice that Haiku only supports, then to me it sort
of defeats the purpose of the multi-platform API.
Qt wraps some platform specific code with its API. The native Windows and Mac GUI have been reproduced, the same can be done with Haiku. I'm also pretty confident that the special dialogs like open/save can be replaced with the BFilePanel.
Also I think Haiku has some advantage over a brand new OS in that we
have a decent library of BeOS software it can run. As long as the
source code wasn't lost and they can be updated, this seems like the
best way to get apps on the system.
It's the best way for me too, but I feel Qt is such an important library. It would help porting software that won't be ported otherwise. That said, I hope Qt won't become the framework of choice on Haiku, the native API should be used for new native applications.

Other related posts: