[haiku-development] Re: R1/a4 initial planning

The futures is open standards aka css3, html5 and js (dart, etc).
I like the BeAPI and it is good, we make yab and used the pure BeAPI and
have a good result and many good programms are born (Jaba - the burn app
and more).

I like to see Haiku-OS r1 with a verry new Interface for  make good sizable
and localise apps.
When i have a vice i vote für html5,css3 and js, this is verry fast coding
, flexible and easy to customise.
With a backend from a webkit or a new reder with no backward to html4,css2
etc..

And i hope Haiku found more developers he can work on port to other arch
(arm9, arm11 etc.)

I think Haiku need more look to portable coding.

PS: AGG is good backend!

Ralf

Am 1. März 2012 15:07 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:

> 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.
>
> > 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.
>
> 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 also can't say I see a lot of cases on Linux where standard widgets are
> misused (can't think of any ATM).
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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).
>
> > 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.
>
> > 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.
>
> CU, Ingo
>
>

Other related posts: