[interfacekit] Re: UI Widgets?

>I guess I misphrased that.  My question is this:  What business does an
>app have doign making direct drawing calls to the server?

All the business in the world.  How do you think all the 3rd party 
components draw themselves?  How the heck is my super-spirograph 
brain-mutator app going to do its thing?  By using the BView drawing 
API, which, in turn, sends messages to app_server to do the job -- just 
like the native widgets.

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

BWindow is an interesting exception to the rule (and, to my knowledge, 
the only one): it *is* drawn in app_server.  There are a couple of 
reasons for this.  First is that as fast as communicating to app_server 
is, it's still faster to do it internally, and since window frames are 
at the most basic level of UI interaction (namely, moving windows about) 
it's important for the drawing of windows to happen as fast as possible. 
 Second, app_server needs to be able to manage the window even in the 
case of an application hang in order to maintain interactivity.  Drawing 
the window is, of course, an essential part of making it interactive -- 
if you can't see it, you can't interact with it.

>Other widgets would do the same.

They don't in R5, and they won't in R1.

>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

There will be no themes in R1.  Period.  We'll look at this in R2.  I 
might mention that after the last couple of years of 
everything-must-be-theme-able madness, an awareness is growing that 
themes actually interfere with the smooth operation of a 
well-constructed system, rather than making the system more accessible 
by allowing the user to tailor the interface.

>like an incredibly facile way of managing the coding.

As I explained to Nathan Whitehorn on the GE list, rendering primitives 
(StrokeLine(), etc.) are not at all in the same category as objects 
which use them in order to draw themselves.  app_server, with the 
logical exception of BWindow, is in the business of providing rendering 
primitives, not knowing how to draw widgets.  The primitives and objects 
which use them are at different levels of abstraction, and as such do 
not benefit from being lumped together.

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

I hate to rain on your parade, but if your document supposes that 
widgets are drawn in app_server, I can assure you that you're barking up 
the wrong tree.  If you don't believe me, feel free to bug the ex-Be 
folk.  A lot of new abstractions were introduced in Dano, but even 
there, widgets do their own rendering.

My apologies if I seem harsh -- I've just endured more "it should be 
like GTK/Qt/TinyPTC/etc." than a man should have to. ;)  This is our 
architecture, and we're running with it -- it is a done deal.

e

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: