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 > >