[interfacekit] Re: app_server specs

>That's exactly my point of view. We need a service that know how to 
draw
>common widgets.

Again, what about 3rd party widgets?  If we're putting the BeAPI widgets 
in app_server, why should they have to use the BView drawing API?  Why 
not just patch app_server so it now draws their widget, too?  But wait, 
we could make them add-ons loaded by the app_server!  Just put your 
widget in an add-on!  And this would be fundamentally different from the 
current architecture *how*?  Why go to all that effort when you can just 
use the BView API for what it's meant for:  drawing things!  Of course, 
there's the additional issue of exactly how these widgets get exposed to 
client apps for use.

>This modular design give us many advantages :

This is funny to me, because stuffing client code into the server 
actually reduces our modularity.

>- Easier to implement / manage / update the GUI look

How?  You still have to write new code, regardless of where you've put 
it.

>- Easier to implement a skineable GUI

How?  If you go the bitmap skinning route, there's no reason the bitmap 
can't be loaded by the widgets.  If you use some kind of meta language, 
it still has to be interpreted *somewhere* -- and where really doesn't 
matter all that much.

>- Third party soft like RAD tools can take advantage of this service to 
draw
>widget without the need of creating the widget itself.

This makes almost no sense whatsoever to me.

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

I'm starting to feel like the resident crank here. =)  Again, please 
forgive me if I'm too abrasive; I've had these discussions far too many 
times, and this week sucked on top of that. =P

e

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

Our chief want is someone who will inspire us to be what we know we 
could be.
        - Ralph Waldo Emerson, writer and philosopher (1803-1882)

Other related posts: