[haiku-development] Re: R1/a4 initial planning
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 29 Feb 2012 18:32:32 +0100
On Wed, Feb 29, 2012 at 03:24:21PM +0100, Stephan Aßmus wrote:
> And then you may have a few bigger applications installed, each of
> which make use of a lot of the same features in the platform. Such a
> system is obviously more lean, than if the platform is much smaller,
> and each of the bigger apps has to implement a lot of stuff on their
> own. The Be API is somewhere in the middle. There are the various
> kits, but usually, bigger apps have still to implement a lot of
> stuff on their own. Qt applications have the potential to share more
> code, since Qt itself is much more complete.
I'm not so sure about that. As I look at some Haiku applications, I see
the main part of them is usually made of custom widgets that don't seem
worth sharing. Examples are the terminal view, the pose view in tracker,
the analog clock in time preflet, or WonderBrush's drawing canvas. This seems
to apply to both small and bigger applications on Haiku.
It may not be the same on other platforms,
and I think this is a direct consequence of the API. By providing just
the right amount of stuff, the BeAPI makes it easy enough to perform the
boring parts of your app in a few lines of code (opening up a window,
adding a menu and some buttons, and reacting to events); while allowing
you to be more creative with the core parts of the app where you
actually need it.
A smaller/more restricted toolkit would lead to too much custom widgets,
and a non-uniform look and feel by everyone rewriting the same code
(think X11). On the other hand, a toolkit with more widget flexibility
will result in apps that try to use these standard widgets everywhere,
mostly by programmer lazyness. The result is that the widgets often get
misused, sometimes in confusing ways. Having the possibility to create a
custom widget might not be enough, the BeAPI manages to make it part of
the programming philosophy so you don't feel guilty when doing it. The
ability to subclass existing widgets also allows a smooth transition
between standard and custom ones.
As an example, the wxWidgets API allows the creation of custom widgets,
but has no way of subclassing existing ones. The result is that an
application developper will use existing widgets whenever possible, and
likely overuse them in places where a custom one would be better. Then,
when there is really no way left, they have to spend a lot of time
learning how to write a custom widget. Tools for UI design have the same
problem, they put you in the mood for "standard widgets only" (even if
adding custom widgets is allowed). When a custom widget doesn't blend in
the API, it feels like a hack, from the programmer point of view and
often from the user's one as well. The BeAPI has features that allows
plugging in at many levels and with good support for the whole range of
features : layouting, archiving, thread-safety, drag'n'drop to name a few ; all
of this without having to write thousands of lines of code.
The result is good for both programmers and users: no creativity limits,
good integration in the existing world, and a coherent look&feel despite
the amount of drawing that is actually made by application custom code.
From my personal experience, working with any other API (I didn't try
all of them :)) was sometimes easier in the early phases, when you only
need standard widgets, but as applications get more complex, you
encounter more and more limits (either performance problems, API design
limitations, or implementation bugs) until you give up out of
frustration.
Well, this is what I feel when using the BeAPI for developping. I'm all
for improving it in the same direction, and last time I tried Qt, I
didn't think it was the same.
As an example, look at Qt serialization API, QDataStream:
http://doc.qt.nokia.com/4.7-snapshot/datastreamformat.html
Here we have a small set of supported classes, that are mostly an
extension on "primitive types". And, there is no way to extend
QDataStream to support for more types. So, you have to come up with your
own code if you want to send some C++ objects to a file, over the
network, or to another application. On the other hand, the BeAPI offers
you BMessages and BArchivable. Not only this can be used for most of the
classes in the API, including archiving a whole BWindow with all its
widgets, but it is also very easy to add support for it to your own
classes, making it a much more generic tool that can be used in many
cases. BMessages also have binary stability accross BeOS versions (and
hopefully Haiku versions as well), making it actually usable to share
data over the network, or store it and load it much latter on another
version of an app. You can see that QDataStream has different versions,
and this is not backwards compatible unless the application asks for it.
--
Adrien.
Other related posts:
