[haiku-development] Re: R1/a4 initial planning
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 1 Mar 2012 19:06:29 +0100
On Thu, Mar 01, 2012 at 03:07:15PM +0100, Ingo Weinhold wrote:
> On 2012-02-29 at 18:32:32 [+0100], pulkomandy <pulkomandy@xxxxxxxxxxxxx>
> wrote:
> > 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.
>
> I assume you mean the main part uses custom widgets. Because even those that
> do mostly use standard widgets.
Yes, of course. But what makes an application a "killer app" is what
happens in the carefully created custom parts. The rest is just boring
settings dialogs :)
> >
> > 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, sometimames in confusing ways.
>
> That's a rather misty-eyed assessment of the actual situation. Since a
> table/column list view was missing people either made do with a simple list
> view, implemented their own, or used a third-party one (Santa's). Since
> number spin boxes or date/time edits were missing, people made do with a
> simple text control (or in case of the Time preflet implemented their own).
> The lack of action and undo frameworks forced everyone to make their own. So
> no, the Haiku API is by far not complete enough.
I didn't say we shouldn't touch anything in the API, of course it is a
good thing to improve it and add these missing parts, and replace the
badly designed ones. Interface Kit is the part that needs the more work
in this area, maybe this is why Qt, which has a better UI API, sounds
good. But on the other hand, I feel the BeAPI is actually better at the
core, with the BApplication and BMessage/Looper/Handler paradigm, an
approach that works for inter thread messengin, inter app, accross
memories (RAM vs mass storage) and even
accross computers through the network. Can you find anything as coherent
as that ?
>
> I also can't say I see a lot of cases on Linux where standard widgets are
> misused (can't think of any ATM).
Not in the most well known apps where people have thought about it and
took the time to make things right, which is never impossible.
>
> > 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.
>
> Huh? As written in a earlier mail, with respect to subclassing I think Qt
> works very similar to Haiku's API, while it has the advantage that
> subclassing is needed a lot less.
I was thinking more of wxWidgets there. Qt may be fine, I never wrote a
custom widget for it. How easy would it be to write an hex
editor/viewer, or a spinbox showing an hexadecimal value ? These are
examples of things I needed to do and had to hack around in wxWidgets.
On Haiku I know I can do them without too much work.
>
> > 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.
>
> I guess the subclassing restiction is because wxWidgets wraps the native
> widget implementations. IIRC SWT has the same limitation for that very
> reason. It doesn't apply to a lot of other tool kits, including Qt.
I was quite happy with SWT in that regard when I worked with it. For
example, a List control can be made horizontal and display pictures
instead of text items, and support drag'n'drop of the items with visual
feedback, all of this with a reasonable amount of code for a widget that
is not the central part of an application, and most of it being easily
reuseable.
I notice that such a custom list needs chenges from the default
behaviour in both the model and view, so I'm not sure Qt would be
flexible enough (if I have to replace both the model and view, then
what's the point ?). I don't remember how Qt's storage in the model is
done and how the view accesses it. Is it callback-based ? Does it scale
well to huge amounts of data ? I know wxWidgets is bad at doing tables
with a lot of data (I once needed 128K cells and that was too slow, so I
had to cheat), while UIP handles it fine and with very few code to
write.
As I remember it, the Qt system needs a rather big amount of work to
just get your list/table displaying some data, but once that's done, its
quite easy to add more features to it (an icon with text, or whatever).
I feel, but maybe that's just because I'm used to it, that there isn't
such a big first step in the BeAPI.
>
> > 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).
>
> That is not the case in my experience. It may be different for you, but that
> is hardly a reason to blame a tool that saves you work.
It saves you work as long as it's powerful enough. Qt Designer is quite
good for that, but wxFormBuilder is not, for example. The problem
with these tools is a bit like what happens when you use an IDE to drive
the build system of your projects: it's always hard to get out, and even
harder to jump back and forth between the tool and hand work where
needed.
>
> > 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.
>
> This is really nothing unique to the Be API (in fact the Haiku API, since the
> former didn't even have layout management).
It's a feature any well-designed API should have :)
I always get into trouble when trying to use drag'n'drop in linux,
accross apps I can understand that this is a problem of using different
toolkits, but inside an app I can't think of anything else than 'the API
needs too much work to get it working, and the programmer was lazy'). In
Haiku it is just one more BMessage to handle, and it is quite widely
supported.
>
> > 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.
>
> Again, that is not my experience. In terms of limitations and poor API design
> it's actually the interface kit that comes to mind.
>
> > 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.
>
> I haven't worked with it yet, but as documented you would simply implement
> the operators << and >> for your data type.
Yes, that works, but the problem is the lack of support for it accross
the API itself. Your data type often uses containers such as lists,
vectors and whatnot from the Qt API, and these don't support it, so you
have to do more work than needed. If all of this was supported out of
the box, using the API would be much simpler, and in the BeAPI, it is.
>
> > 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.
>
> The QDataStream API seems to be similar to BSerializable with the difference
> that it is non-intrusive and has an error state (yay!). So indeed it is not
> comparable with BArchivable.
>
> So far I haven't seen anything in the Qt API similar to BMessage or
> BArchivable. They would make good Haiku specific extensions (or it might even
> be possible to get them into the official Qt).
>
> Regarding BApplication, BWindow, and BView being archivable, I find that
> rather useless (we had this topic in an earlier thread about session
> management). I believe so far I have used BArchivable only for own
> (model/data) classes.
I can see it being useful in some cases. One could archive a window at
application build time and unarchive it at run time instead of building
it piece by piece with a lot of function calls. I'm not sure if that
would be faster.
But being able to use it with a BString, or generic data containers,
would be very helpful. An example of that would be boost::serialization,
which has support for most STL containers.
Anyway, this was just an example. On the UI side we have a lot of work
to do to catch up, but the API philosophy doesn't feel too bad to me (it
may for others). On the other hand, I find that the lower-level parts
are quite powerful : ease of use and flexibility of load_add_on versus
Qt plug-in system, inter-application features, support for threads and
TLS everywhere and in an easy way with BLooper/BHandler, where Qt just
has QThread, and also the way all of it just fits together (network,
inter thread and inter app messenging using the same BMessage is an
example). The result is that you don't get lost looking at the kit list
of the Be API, which brings a lot of powerful features with a small
class set, whereas Qt has no such thing, (almost) everything lives in
the same documentation page (a notable exception is Phonon). To me it
seems easier to replace the interface kit in Haiku than to replace some
lower level parts of Qt to bring in all the features we have.
>
> CU, Ingo
>
Other related posts:
