[haiku-development] Re: R1/a4 initial planning
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 23 Feb 2012 22:16:54 +0100
Axel Dörfler wrote:
> 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.
I don't think that is true. In the API I've worked with so far I've seen
Windows/Mac/Unix specific extensions. ATM I can't think of a single example
where Qt uses the least common denominator approach. While the single threaded
GUI might be a hard Windows constraint, AFAIK it is the standard way how GUI is
done on all three platforms.
> 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.
Wasn't that the plan anyway? :-P
> That needs an
> enormous amount of man power, too.
Yes, porting the apps would be quite a bit of work. However, don't forget that
the interface kit needs to be largely rewritten anyway, though, which also
requires significant changes in the applications. It is also worth noting that
for GUI-heavy applications like the preflets, using QtDesigner will save a lot
of time.
> 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.
I don't really see a large number of those changes. For entry_ref I think of an
extra class for (automatic?) conversions between entry_refs and paths. Not sure
if any changes in the Qt classes would be required at all in this case. For
working with file attributes a separate class would be possible as well (rather
than adding methods into QFile and QDir). ATM I can't think of any Haiku
specifics that really have to be implemented in the Qt classes themselves. I
believe most can be implemented just as well or even better in classes on top
of Qt.
> 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.
If a ported application is superior and can be integrated as well as the
corresponding native app, then replacing the latter sounds like a sensible
option. There still might be reasons not to do so. Like the planned development
path for the native application making it better than the ported one, or the
ported application have such a bad code base that forking it would not be a
practical option should the maintainers decide to "focus shift".
So, sure hacking your own code is fun and having full control over it is nice,
but particularly when resources are limited this should be weighed against the
benefits of using a third party application. Generally I don't think that the
authorship of the code as such contributes to the identity of Haiku. After all
most of the code that ships with a Haiku release has not been written by Haiku
contributors anyway.
> 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).
Yes, there are a few things that are not so nice. Nothing that I would consider
a deal breaker though.
> 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.
Well, that is really the core point. Of course it would be cool to take the
best ideas and designs from all existing frameworks and create the perfect
Haiku API. IMO it is also utterly unrealistic given the manpower available.
Taking code and molding it into our API is also a lot more work than just
porting a given framework and putting our extensions on top of it (besides that
from what I've seen so far I think I want to meddle with the Qt implementation
as little as possible), particularly in the long run, where in the latter case
we could just benefit from the work done by the maintainers with relatively
little maintenance overhead on our part.
Moreover, I find the porting aspect rather important, too. And I don't mean
only the porting applications to Haiku direction. We all know that Haiku is not
a viable target for commercial applications. Wouldn't it be cool, if you could
develop such an application on Haiku and invest only little more time to "port"
it to the for-the-money platforms?
> 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)?
No clue, maybe they liked templates, too? So far I've experienced the
limitations of moc only as minor nuisance (things like having to pull out an
inner class to be able to use signals/slots or having to create a base class
for a template class). And you can say what you want about them, using signals
and slots results in less code than an equivalent implementation with BMessages
on Haiku.
CU, Ingo
Other related posts:
