[openbeos] Re: Visual design stuff again

  • From: "Simon Taylor" <simontaylor1@xxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sat, 27 Sep 2003 16:09:41 +0100 BST


> > > The look of R5 controls is hard-coded. Providing the possibility 
> > > to
> > > switch
> > > between different looks would require massive changes, namely a
> > > framework
> > > to support this (i.e. a skinning framework). Since it was agreed,
> > > that no
> > > major feature should be added to R1, this is just not going to
> > > happen.
> > 
> > I was thinking similar to windows XP - not a whole skinning API 
> > (there
> > is a whole different discussion on whether we actually want that, 
> > but
> > that is definately one for GE ;-)). Namely, the ability to switch
> > between "old" and "new", both hardcoded.
> > 
> > My initial thought was to do this by an environment variable, 
> > possibly
> > in home/config/boot/UserSetupEnvironment - Be did something similar 
> > to
> > change to R4 audio subsystem.
> I don't know about the audio subsystem you're referring to, but in 
> case of 
> the look of the interface, what had to be done would be to explicitly 
> handle two hardcoded looks in the Draw() method of every widget 
> class. And 
> there's a good chance that for some controls this also has to be done 
> for 
> other hooks, like Mouse{Down,Up,Moved}() (maybe also for 
> AttachedToWindow(), AllAttached() and perhaps even for the 
> constructor). 
> This is too ugly a hack, that I would even consider it. And it would 
> have 
> to be undone completely, when (if) we consider a more general system.

from UserSetupEvironment (/home/config/boot/):
# The following variable causes BeOS to use the old, pre-R4 audio 
# subsystem (server and drivers) which may improve compatibility 
# with old programs. You will, however, not get all the benefits 
# of the new media system, such as video in/out and user-settable 
# sounds.
#       export USE_OLD_AUDIO=true

Yes, there would be two hardcoded looks in the Draw() method. I dont 
necessarily see this as a hack though, as there are already a lot of 
conditions in each Draw method:

if (IsEnabled())
   if (Value())
   } else {
   if (IsFocus())
} else {
...it would just be a case of wrapping another if (NewLook) around 

I don't see why you would need to do design-specific stuff in other 
methods for the huge majority of widgets. OK, so a curved button might 
need a different check for a hit in MouseDown, but other than that the 
sizes of the controls and the active areas should stay the same.

If we want skinning, this is obviously not the way to go about it, and 
R1 is also not the place for that kind of thing. But if we want a new 
look, while keeping the possibility of switching back to the old one, 
it seems like an acceptable solution.

As you imply, it is by no means certain that OBOS will ever provide 
full skinning support. I know from private mails that Michael and Erik 
are both opposed. That is obviosuly a discussion for GE. But if it is 
decided not to implement skinning support, will the widget set always 
look like R5?

If the decision is made to implement full skinning support in a future 
release, just about all the widget code will need rewriting - it will 
be much more work than just "undoing" my proposed changes.

Without trying this out, it's very difficult to know exactly how many 
changes are going to be needed. I fully agree with you that if a lot of 
different methods need conditional code in them, then it would seem 
like too much of a hack. That's why I still intend to try it with a few 
controls to see what is really needed. I still believe that it could be 
a worthwhile change for R1.
Finally I think a new look also fits in quite well with the R1 
philosophy - not adding additional functionality to the controls, or 
completely new controls - just the existing controls implemented better 
(as in with a more modern appearance). I think implementing a control 
differently visually is akin to implementing an API differently in 

> [...]
> > Seriously, my last post on the topic ;-)
> We'll see. :-P

Yeh, OK, OK - I didn't know you were going to reply :-D
I'll make no such promises this time ;-)

> CU, Ingo


Other related posts: