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

It sounds a lot like we should complete a working port of Qt, but not
replace the Haiku API with it; at least not directly. It also sounds like
there needs to be some additions to the Haiku API to support missing
functionality. Finally with that in place we can write some easy wrappers
that call into the Qt API when building Haiku if they need to be mixed. I
also have put it on my list to build something more significant with Qt so
that I can speak more accurately to this topic but one thing that really
sings to me is the ease of use of the Haiku API (for basic applications).

If we need to write better bordering code for our widgets, then we should
implement and improve on the Haiku API and provide more function UI pieces
that others can leverage. I don't see the need to throw it away because
it's missing some pieces we could either add or improve on. It does sound
like time has progressed and most other APIs for other operating systems
now provide easy ways to do some flashy things that are much harder to do
in Haiku. All this means is we need to start adding some more of these
bells and whistles to catch up.

On the subject of a R1/a4 release, I think we should ensure as many of the
gnu core utils, binaries and libraries we ship with are up to date. These
usually don't require a lot of effort to do but help immensely when
building open source code.

Thanks,
Gabriel



On Fri, Feb 24, 2012 at 12:25 PM, Rene Gollent <anevilyak@xxxxxxxxx> wrote:

> On Fri, Feb 24, 2012 at 3:20 PM, fano il primo <fanoilprimo@xxxxxxxxx>
> wrote:
> > Add a sort of sprintf() to BString? Or the arg as in Qt (but it's ugly
> > again) IMHO use a sprintf wirth normal ARGS know to everibody is
> better...
>
> That already exists, see BString::SetToFormat().
>
> As for parsing a BString into an integer, while there isn't a direct
> member function currently, this can trivially be done via calls like
> strtod and friends.
>
> Regards,
>
> Rene
>
>

Other related posts: