[haiku-development] Re: R1/a4 initial planning
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 02 Mar 2012 04:12:39 +0100
pulkomandy wrote:
> 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:
> 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 :)
I don't see a direct relation between "killer app" and custom widgets. I
certainly don't agree with your argument that a less capable API results in
better applications because more custom widgets need to be created.
> 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 find most of the app kit nice, too, but I wouldn't go overboard with the
praise. The event loop mechanism in Qt is rather similar to how
BLooper/BHandler works, with the difference that the events are typed. Which
IMO is much preferrable for event handling and intra-app communication. In the
former case the BMessage::Find*() calls are just silly -- with typed events the
data can be accessed directly via getters. In the latter case it is very
annoying to send objects around. Either you archive them -- which could be
expensive or might not even be possible -- or you send a pointer -- which
requires object lifetime considerations (e.g. transferring references, which in
turn requires explicit handling of all possible points of failure in the
messaging process).
For inter-app communication and storage purposes where compactness is less of a
concern than forward compatibility BMessages are a good tool.
> > > 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 guess one could simply use a QTableView and provide a model with a single row
and an arbitrary number of columns. And sure, images are supported.
> I don't remember how Qt's storage in the model is
> done and how the view accesses it. Is it callback-based ?
It's done as models are supposed to be done (according to the design pattern):
There is a model interface that needs to be implemented, providing access to
the data plus a listener mechanism.
> Does it scale
> well to huge amounts of data ?
AFAIK it does. I believe model-view based approaches are usually rather good in
this respect.
> 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.
For a read-only Qt list model the "rather big amount of work" consists of
implementing rowCount() (returning the number of rows) and data() (returning
the data item (e.g. a string or an icon) for a given model index). For a
read-only table model columnCount() (take a guess) needs to be implemented in
addition. If the model is mutable it needs to call respective notification
methods upon changes. If it shall be editable via the view too, setData()
(setting the data for a given model index) and flags() (returning flags (i.e.
whether a cell is editable/selectable/...) for a model index) need to be
implemented as well. So, not only is the amount of work required for the basic
task rather small, the overhead increases only modestly with the task becoming
more complex. Good luck with the editable BListView or with sorting and
filtering (which is solved in Qt via a simple proxy model).
> > > 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.
Can't say much about that wrt. to Qt. So far I've only implemented drag-sorting
in tree views which wasn't particularly complicated.
> > > 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.
You really should read the documentation before making such a statement:
"The Qt container classes can also be serialized to a QDataStream. These
include QList, QLinkedList, QVector, QSet, QHash, and QMap. The stream
operators are declared as non-members of the classes."
And:
"In addition to the overloaded stream operators documented here, any Qt classes
that you might want to serialize to a QDataStream will have appropriate stream
operators declared as non-member of the class ..."
> If all of this was supported out of
> the box, using the API would be much simpler, and in the BeAPI, it is.
Huh? The only container the Be API provides at all is BList and that is neither
serializable nor archivable (in fact it really can't be in a meaningful way,
nor can BObjectList).
CU, Ingo
Other related posts:
