Le 23/02/2012 22:03, Alex Wilson a écrit :
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.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.
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 ?)
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.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.
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.