[openbeos] Re: Visual design stuff again
- From: "Simon Taylor" <simontaylor1@xxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 27 Sep 2003 16:09:41 +0100 BST
[snip]
> > > 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
that.
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
code.
> [...]
> > 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
Simon
Other related posts:
