Le 23/02/2012 06:00, Ingo Weinhold a écrit :
I used it for some time, and I find it much better to work with the Haiku API. The main problems I have with Qt are : * Use of the moc preprocessor before compiling in C++. This isn't needed at all, as the BMessages in Haiku shows, and it only create problems (files getting out of sync, hours of tracking weird bug because you didn't put Q_OBJECT in your class declaration, ...) * Does not integrate with anything else. Qt has its own way to do threads, sound, handling strings, and so on. * While the model/view framework for lists, tree and tables works quite well, when you want to do something that doesn't fit with it you have to write a huge lot of code. With BeAPI it's really easy to come up with your own custom controls, which really helps with user interface creativity and simplicity. Most others UI toolkits have the same problem * I don't understand the layout system used by Qt. But maybe that's just me :)Ryan Leavengood wrote:On Wed, Feb 22, 2012 at 7:28 PM, Ingo Weinhold<ingo_weinhold@xxxxxx> wrote:Since I started poking "delicate" matters already, I guess I can throw in my opinion about Qt and Haiku's native API. I think we should consider Qt as base of the Haiku R2 API, replacing most of the Be/Haiku C++ API. Haiku specific extensions (like support for extended attributes) could be implemented on top of it or directly in the standard Qt classes.It isn't a terrible idea really. I have not extensively look at Qt or programmed with it but from what I know it is pretty good.
I don't find Qt any better than what we have now. And our API can still be improved a lot. I've tried various solutions when I had to work on other platforms (Qt, wxWidgets, and some others), and none of them was as nice as the BeAPI. The BeAPI has a good balance between "get started with hello world app in 1 minute" and "write very complex app with lots of widgets". You start with fewlines of code, and then it grows linearly (or maybe even slower than that). With some other systems, it gets exponential because you end up rewriting everything. The ability to override some beaviour of a class in Haiku is very useful for that, and most others have a much more black-box approach.Plus there is the nostalgia of the BeOS API, and even the sense of "branding" in Haiku having its own API. If Haiku becomes just another Qt platform it might be easier for people just to lump it in as "yet another Linux."I find sticking to our own API just to have a marketing bullet point not a sufficient reason for doing it. Particularly when the alternative is better.
The integration is the key. Not only it makes things much pleasant for the user, it also allows the developers to work very fast (look at the work done and at the small development team, compared to other OSes).To further push "delicacy", at what point does Haiku just become pointless?That's a good question. In fact all the BeOS buzzwords (file system with queryable metadata, media OS, pervasive multithreading, well-designed C++ API) either don't truly apply anymore (because some other OS does it better/at least as good) or have become meaningless. I think a niche for Haiku is to be a well-integrated open source OS that doesn't get in the user's way.
I'm wondering what Qt would bring us ? Maybe some apps like KOffice and Arora web browser. But I guess we would end up running KDE (the window manager that starts in more time than Haiku needs to boot) ? Or is the plan to rewrite all of our existing apps, preflets, deskbar&tracker to use Qt ? Because that sounds like it's more work than building a web browser and office suite using our nice API...
-- Adrien.
