[interfacekit] Re: UI Widgets?

I'm not an expert in GUI engineering, but is there a way to keep the actual
drawing code away from the app_server AND the widgets, by using a third
entity (i.e. service) ?

I know you'll say it's not a good idea, but I really want to know why (I
came in this project to learn ! )  :-)

thanks
Steve


----- Original Message -----
From: "Erik Jakowatz" <erik@xxxxxxxxxxxxxx>
To: <interfacekit@xxxxxxxxxxxxx>
Sent: Wednesday, February 13, 2002 12:41 AM
Subject: [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: