[interfacekit] Re: app_server specs

That's exactly my point of view. We need a service that know how to draw
common widgets. This modular design give us many advantages :

- Easier to implement / manage / update the GUI look
- Easier to implement a skineable GUI
- Third party soft like RAD tools can take advantage of this service to draw
widget without the need of creating the widget itself.

I think it's definitely the way to go.  Ideas everyone ?


----- Original Message -----
From: "Isaac Yonemoto" <ityonemo@xxxxxxxxxxxx>
To: <interfacekit@xxxxxxxxxxxxx>
Sent: Wednesday, February 13, 2002 12:09 AM
Subject: [interfacekit] Re: Re: app_server specs


>
>
> > Nope. If you look at prototype 4's source, you'll notice that there
isn't any
> > drawing done by the test app. The only thing it does is make a bunch of
> > messages and fire 'em off to the server.
>
> I guess I misphrased that.  My question is this:  What business does an
> app have doign making direct drawing calls to the server?
>
> Is BWindow going to be doing the drawing of the window, or is
> app_server?  If it is, then that makes for a rather hefty BWindow looper,
> each time a new BWindow is created.  Instead, why not use a picassoesque,
> which knows the "draw window with bounds XYXY and with attributes
> MMMM" language, and does all the nitty gritty.  "picasso" then draws it on
> its own time, as called by the app_server internally.
>
> Other widgets would do the same.
>
> This would allow a set of plugins for themes to be loaded by app_server
> itself (which means Binary compatible themes in R1!!).  This also seems
> like an incredibly facile way of managing the coding.
>
> I have a document which describes how I think app_server circa R5
> operates, should I publish it?  I'd also be willing to put time into
> developing most of the components I enumerate.
>
> Isaac
>
>

Other related posts: