[interfacekit] AW: Re: Widgets and the appkit

I agree with Erik. All UI widgets should draw themselves via appropriate
drawing functions of the BView. Themes can be also implemented using the
design used in R5. E.g. by drawer classes.

Imagine a BButtomDraw class which is implemented as a singleton. This class
could be implemented in libbe.so.
Within the draw function you would call

BButtomDraw::Instance()->Draw(this) ;

the BButtomDraw could look like this

class BButtomDraw
{
public:
  static BButtomDraw* Instance()
  {
    if (fInstance == NULL)
      fInstance = new BButtomDraw() ;

    return fInstance ;
  }

  // this function configures how the buttom should be drawn
  void Configure(parameters) ;
  void Draw(BButtom* buttom) ;

private:
  static BButtomDraw* fInstance ;

  //Members to describe how the BButtom is drawn
} ;

BButtomDraw* BButtomDraw::fInstance = NULL ;

You can consider this solution as a kind of drawing service.
This is just one idea. I'm shure there exist several different solutions but
this one would keep the design of R5 with theme support. Furthermore, the
different ideas of implementing a theme engine can be exchanged easily just
by rewriting the BButtomDraw class.

Concerning GUI builders: They just need to add the wanted elements to the
view where they
should be drawn - what's the problem??? Why not writing a BTVView to allow
TV apps to be written with less effort?:)
I think it is not the task of the interface kit to help certain apps to
solve their task. An API is a common interface which provides services for
all kind of apps.

But this should all be future - R2!!!!!!!!

>In short, no.

>At length, the app_server's responsibility is to provide services; in
>this case, the service it provides is an API for drawing arbitrary
>raster and bitmap graphics.  I can assure you that Be's implementation
>did *not* have the widget drawing code in app_server.  As far as OBOS is
>concerned, there will be widget-specific drawing code in app_server over
>my dead body.

>Having made that rather dramatic statement, ;P I'm not really following
>you on this notion that widget-rendering code would be "conserved".
>What, precisely, is being conserved and how so?  Only a button draws
>itself like a button -- a different kind of widget drawing itself as a
>button would be misleading, at best.  If it looks like a button, it
>ought to *be* a button.  Now, if a developer wants a different sort of
>button that still draws like a button, then s/he simply derives from
>BButton and doesn't overload Draw().  Perhaps this idea of widget
<drawing in app_server has something to do with themes?  If so, we're all
<clever enough to figure something out that doesn't pollute app_server.

>Anyway, if I'm missing the point, please enlighten me. =)

Other related posts: