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 >