[haiku-development] Re: R1/a4 initial planning
- From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 23 Feb 2012 23:11:01 +0100
Le 23/02/2012 22:03, Alex Wilson a écrit :
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.
The problemwith switching to a completely new API is we just lose our
existing application base. So, either we start over with 10+ years of
rewriting/porting our own apps to a completely rewritten API, or we try
to improve the existing API where it is broken (maybe drawing
inspiration from Qt or others), while not completely dropping it. This
way apps can be migrated more easily.
If we go for Qt and start rewriting the apps, it's likely that we get to
just recompile the existing ones. Unless we keep the old API available
side by side, and in that case it's likely that many apps will never get
ported at all and we will get 2 ways of doing UI, leading to
unintegrated feeling (how would drag'n'drop work from a BMessage based
app to a signal/slot one ?)
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.
There wer eplans to port the BeAPI to others OSes. GoBe did something
like that (closed source) for their office suite, and there was the
BlueEyedOS project as well. But, it didn't really go as expected because
the consistency of Haiku, visible in the way you use it, is also
applicable to the way you develop app for it. From kernel hacking to
user interface design, things just fit together and that makes it nice
to work with.
I have a bad experience of any other framework I tried to use on that
regard. You often need to use something that's not in the framework,
want to use an extra library, and must use several different APIs. This
may not happen with Qt as the only way to work around all the OS, but as
far as I know, they don't do kernel ?
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.
I'm all for improving the current API.
On the other hand, I'm not sure about that border thing : first, I'm not
sure why you would want a control to get just a non-standard look. I see
apps in Windows coming with their own UI look, and it doesn't feel like
a good thing.
With the BeAPI, it is also possible, very easily, to design a custom
control with its own drawing code for specific purposes. And with the
be_control_look class, you can get it to blend in the interface by
reusing the same look (gradients, colors, and so on). This makes it
possible for me to be creative in the way I design my UI. I don't need
to spend time working around API limitations. I usually manage to get my
UI look just the way I want it.
There IS room for improvement in the API, classes like BOutlineListView
should be completely recycled, for example. But the way to work with it
seems rather good to me. Maybe I've just grown used to it, but I feel it
has the right balance of powerfulness and ease of use. I think there is
no need to drop just everything and start from something else. This
would just mean rewriting most of the existing Haiku code, which I don't
think makes sense. On the other hand, improving the API has proven to be
viable, as you know, with the addition of the Layout Kit, for example
:). A compatibility break will allow these new features to blend in
better in the existing stuff. Model/View enabled classes in the
interface kit might be useful in some cases, but from my experience they
are not as flexible as the current BeAPI way (or at least not useable in
the same cases).
It is also important to note that an improvement of the existing API can
be done accross several Haiku releases. This allows each release to come
with a small set of changes, allowing apps developpers to catch up.
Compatibility can be done (in both ways, provide new classes for older
haiku releases, and keep old apps running on new releases with a
compatibility layer). On the other hand, I don't see howa complete
switch to Qt could be made smoothly.
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???).
GTK is messy, there are other toolkits that manage OOP in C very well. I
can think of UIP (relies on windows, gtk or motif to do the rendering)
and of Amiga with BOOPSI and MUI. Both of these are plain C, but they
provide object-oriented features and are quite easy to use, even if it
never gets as good as C++.
Other related posts:
