[haiku-development] Re: R1/a4 initial planning
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 2 Mar 2012 19:00:52 +0100
On Fri, Mar 02, 2012 at 04:12:39AM +0100, Ingo Weinhold wrote:
> 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.
>
That's not it. The ability to create custom widgets where needed, and to
easily get them to blend in with other widgets around them, is a great
tool.
Having a limited set of widgets (not too limited, the BeAPI could get
some more) for basic uses is a good thing, but I don't think that
one-size-fits-all widgets are a good solution. In some toolkits, you
start off by using a standard widget, then find it's too limited, and
have to rewrite everything the custom way. So the ability to subclass a
widget not only to add to it, but also to replace parts of it, is useful here.
> > 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 intra app comunication one could go for reference counted objects.
But I like the idea of using the same tools for intra and inter app
stuff when possible. Inter app communication is something that I use a
lot in Haiku, and always get annoyed at others OS that fail to do it.
Drag'n'Drop is the most common example, scripting applications with hey
(or otherwise exchanging data) and many other things are made possible.
The fact that the same tools are used for both result in far less work
to go inter-app and open a lot more possibilities.
Even messaging between multiple instances of the same application can be
useful. For example, I wrote a simulator for the Amstrad/Schneider CPC
computers, and do some z80 development using it. From a makefile, I can
run the simulator, and it will just reload the memory in an already
existing instance. With the BeAPI this is very easy and safe to do, with
wxWidgets it needs some platform specific care, and may be subject to
race conditions if the main instance of the app and a client one are
started at about the same time. Single-instance mode is also a way to
save resources when you allow multiple document windows in the same app
instance, and it also reduces application startup time. It's also how
Android does it. I have no idea about Qt ways to achieve something
similar ?
>
> 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.
Sometimes there is some data copying either from your own actual model
to a not flexible enough "model" class from the UI toolkit, or from the
UI toolkit model to the view.
In wxWidgets, for example, a table with a lot of cells is created on the
view side and everything gets unbearably slow. Again, this is likely
because the native components don't allow it to be done otherwise, but
it's rather annoying.
The model could also enforce some data storage format, which would
prevent on-demand loading (from a file, for the hexEditor example).
>
> > 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).
Ok, that's fine for displaying text and icons. What about a list of
something else, let's say colors or shapes ? Would I have to cheat and draw
everything in the "icon" ? As I remember it you have to go up in the
class hierarchy and use a more generic list, which has much more
abstract methods, and you need to write the matching view and model.
I didn't say BListView was better, but that Qt also has some limits.
Going Model/View (done right) is definitely a good thing.
> > 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 ..."
Ok, good thing ! I must have missed it, would have saved me quite a lot
of time on some projects. (and I did seach for it!)
--
Adrien.
Other related posts:
