[interfacekit] Re: app_server specs

>> >This modular design give us many advantages :
>>
>> This is funny to me, because stuffing client code into the server
>> actually reduces our modularity.
>
>In fact I *never* personnaly proposed that the drawing code to be 
directly
>in app_server.

Ah.  My bad. ;)

>I just wonder if there's a way to collect all basic widget
>drawing code in a single entity that can be, probably, easier to manage 
and
>share. I have absolutely no idea how to implement this, but at a design
>level, I found the idea attractive and practical.

It is very attractive (from a certain perspective), and Be went quite a 
way down the road toward this in order to make BeIA more easily 
customizable for their customers -- who would rarely need anything 
beyond the provided controls.  The question is whether this approach is 
extensible in the way that it should be for a general GUI solution.  If 
you're producing a web-tablet which carries nothing but your software, 
then it's OK if the theme system doesn't automagically adapt to new 
widgets.  Whatever isn't already there, you can write yourself, knowing 
that it only has to look one way -- i.e., the way you, the *vendor*, 
want it to look.

Here's the thing with theming.  Most themable apps don't really allow 
you to do much more than make new bitmaps and/or specify new colors for 
the controls.  The controls stay exactly where they always have been, 
and are the same size they always have been.  In more advanced systems, 
like WindowBlinds and Mozilla, you are essentially *rewriting* the 
widget drawing code -- you're just doing it in a fashion which is 
loadable at run time.  WindowBlinds (and correct me if I've 
misunderstood) *compiles* your theme "code" into an interpreted byte 
stream.  It's reasonably quick that way (though there is a noticeable 
difference in terms of responsiveness), but the last thing I want us to 
be taking on for R2 is a freaking compiling interpreter.  This, all by 
itself, is an *enormous* project.  The Mozilla approach is to run a 
bunch of cascading style-sheets with *huge* numbers of image files -- 
check out the "classic" theme, which consists of 692 files -- an 
approach that is gathering a lot of criticism as slow, buggy and 
unresponsive.  I'm sure we can all agree that these are *not* terms we 
want applied to the OpenBeOS experience. =P  It's also not exactly a 
no-brainer to implement.  I'm not sure how much everybody here has been 
following the Dano "release", but the theming engine that the Be 
engineers themselves came up with is not exactly garnering universal 
praise (aside from being nice to look at).

I should say somewhere in here that aside from advantages with regards 
to a theming implementation, I see absolutely no merit in separating 
widget-drawing code from the widgets themselves.  Windows, due to the 
fact that they're drawn by app_server, are a somewhat different story, 
and much easier to deal with than a general theming solution:  you write 
a window-border addon and app_server loads the currently selected one.  
It's very straight-forward, as windows have a rather narrowly defined 
role to play.  It's generalizing to all the widgets and somehow 
encompassing 3rd party widgets that gets to be a real mess.  And of 
course all of this only addresses the technical aspects of providing 
theming, and says nothing of the usability impact of it.

I'm sure you're all aware by this point that I take a dim view of the 
whole theming *thing*.  If it were up to me, theming under OpenBeOS 
would consist of:

* Making various system colors configurable a la WindowShade (not to be 
confused with WindowBlinds ;)
* Creating a public plugin API for window decor
* MAYBE splitting the widgets into their own library so that daring 
folks can release alternate versions in which they've rewritten the 
widget drawing code.  This, of course, does nothing for 3rd party 
widgets, meaning that all those apps out there using, for example, 
Santa's Gift Bag (and there are a lot of them) would have inconsistent 
interfaces.

All three of these are relatively easy to accomplish, but I don't think 
for a moment that the theme-crazed hordes ;) will find this acceptable.  
So, we're just gonna have to work as hard as we can to give the users 
what they want while ensuring that the system is just a fast and stable 
in its default configuration as it ever was (hopefully more).  Maybe if 
I'm lucky, the rising backlash against theming will crest before we 
start R2 and we can just skip the whole thing.  Yeah, and my next 
lottery ticket purchase will be a jackpot winner. ;)

*Whew*  OK, can we all agree to leave this subject alone until R2?

>As for app_server, I totally agree it *must* keep the leanest possible.

I'm relieved to hear that. =)

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: