On 23.02.2012 01:28, Ingo Weinhold 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. There are a whole bunch of reasons for such a move. The most important one is that parts of the current API (particularly the interface kit) are incomplete, have a rather poor design and thus need to be replaced, and we simply don't have the manpower to do that. Qt certainly isn't perfect either, but it is way more complete and IMO has a significantly better design wrt. GUI classes. And on top of this it is actively maintained.
It's a *very* pragmatic path, though. I for one wouldn't be interested in working on that anymore either; just trying to keep up with Qt development is not really an appealing thing to do with my time (as limited as it is), I prefer to write genuine code any time. Each extension/change would need to be evaluated against the loss of compatibility, and the higher maintaining burden it introduces. Since Qt generally follows the least common denominator approach for platform depending code, that would happen quite a lot, too.
Besides that, though, we would lose our complete application base; it would all need to be ported to the new API sooner or later, especially complex apps like Tracker will probably want to be on the receiving end of new functionality that comes with it rather sooner than later. In the case of Tracker, it would really be a rewrite though. That needs an enormous amount of man power, too. The coding style is very different, too, resulting either in an awkward mix in the ported apps, or just more work. Common concepts like entry_refs would either be needed to removed completely, or hacked into the Qt API, introducing a large number of non portable changes.
And if we throw away most of our applications in favor of existing Qt applications (which would just be the next logical step, as it's less work, and sometimes they might even have more functionality), we also throw away Haiku's identity completely.
Furthermore, while Qt is way more complete (and better designed) than most of the Be API, it comes with its own legacy, and kludges that I don't really see forward to adopt either (like QWidget being a window, too, or even the alien QMainWindow).
Anyway, the basic idea of finding a way to get a head start on an R2 API is not a bad one, and I wouldn't even mind if we take most of Qt's API as a model for our own -- if we take actual code, we would have to change the license of our respective libraries, but that would probably be acceptable, too.
When it comes to slots and signals, though, I don't particularly like them, and I wouldn't want to have that in an R2 API at all. That concept doesn't play well with C++, and 'moc' is really annoying if you ask me. Why not choose a language that has support for those concepts in the first place (like Objective-C IIRC)?
Bye, Axel.
