[haiku-development] Re: R1/a4 initial planning
- From: Alex Wilson <yourpalal2@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 23 Feb 2012 14:03:43 -0700
2012/2/23 Dariusz Knociński <dknoto@xxxxxxxxx>:
> Dnia 2012-02-23, o godz. 10:51:22
> Julian Harnath <julian.harnath@xxxxxxxxxxxxxx> napisał(a):
>
>> Justin Stressman <jstressman@xxxxxxxxx> schrieb:
>> > It pains me to see this talk about ditching the current API (with its
>> > Be nostalgia and sense of nativeness etc) to replace it with Qt.
>>
>> I agree. Personally, I would lose any interest in Haiku if it were to
>> replace its own APIs with Qt. If I wanted to use a Qt-based desktop
>> system, I'd just use some KDE Linux.
>> Haiku-specific API-additions would probably not be used much at all
>> since most "Haiku"-applications would turn out to be straight ports
>> from Linux. To me, anything that is interesting about Haiku would be
>> lost.
>> Just my 2 cents.
>>
> I also agree with that. I have QT every day at work and this is not the
> environment of my dreams. Abandoning its API is the loss of identity :(
> I like Haiku, because it is similar to QNX: fast, small and cohesive as a
> whole. After switching to Qt, it will be rather a QT / KDE hybrid Linux
> like system.
I don't understand where people are getting the idea that using Qt
means we would use KDE as well. KDE is separate from Qt; it is built
with Qt. As Stippi said, if we choose this path, Qt would become
native on Haiku (meaning it would certainly be cohesive). Of course,
we would place a priority on making Qt on Haiku as fast and
lightweight as possible.
In reply to some of the more emotional responses, I have to say that
if the only appeal of Haiku is that it has its own API, which is
almost unchanged from 10 years ago, then Haiku really is pointless. If
that's all we've got going for us, why don't we switch gears and
become the Haiku Framework, and port the API to Windows, Linux and OSX
so that we could have 3 OSs that have all the benefits of Haiku? What
makes Haiku worth using, to me, is the nixishness of it (I've got Vim,
Bash, Python, etc..), the integration of the system (Translation kit,
Media addons), and Haiku's ability to stay out of my way. The API is
just a tool to get things done, and while there are nice parts of it
(the App Kit), I think it's deficient in many ways.
Parts of the current BeAPI (especially the Interface Kit, as Ingo
said) are sometimes a pain to work with. For instance, suppose you
want to add a border to the right of some element; in html (which is a
terrible way to make apps, but it does some things right), you set the
CSS property border-right. In Haiku, you can either add a widget (if
there's one that happens to draw the border exactly how you want it)
or you can write custom drawing and invalidation code, which is a huge
pain. Nobody should be forced to think in pixels for something as
simple as a border. That's just one example, but what I'm trying to
get at is that if we can improve our API without too much work, we can
spend more time polishing and improving what really makes Haiku
special.
Maybe Qt isn't the best way to do this, this discussion is still
*very* preliminary, and people are welcome to suggest alternatives.
Something about Qt that I find pretty awesome is Qt Quick[0]
(disclaimer: I haven't actually used it :P). From my understanding, it
offers faster UI design, better UI/logic decoupling and also lends
itself much better to hardware acceleration. Something I'm not crazy
about with Quick is the use of Javascript for logic. It wouldn't be
too hard for us to create something like Qt Quick in the BeAPI, so
maybe that's an alternative that would get more support from the
community. Another API that is similar to Qt Quick in some ways is
Clutter[1], unfortunately, it's built on GTK, which is just whack (who
would willingly code OOP in C???).
--Alex
[0] http://qt.nokia.com/qtquick/
[1] http://www.clutter-project.org/about
Other related posts:
