[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
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: