[openbeos] Re: Visual design stuff again
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 27 Sep 2003 18:11:43 +0200
On 2003-09-27 at 17:09:41 [+0200], Simon Taylor wrote:
> [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.
[...]
> 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.
My point is, that this way you decentralize a central concept (the concept
of a theme). The straight forward way to handle something like this is to
pull the drawing (and probably also the handling of certain events) out of
the BViews into separate classes, objects of which are constructed via a
central factory. A theme is basically an implementation of such a factory.
So, your `code it into the views' approach is quite the opposite of what I
would consider The Right Solution (tm).
> 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 that is so, then you're probably right, that only the Draw()s need to be
changed.
> 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.
Well, putting work into something, that is thrown away with the next
release, is something I have a bit of trouble understanding as an
acceptable solution. It may only be my philosphy, that when we do
something, we should do it right...
> 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?
Probably not.
> 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.
That's for sure.
> 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.
Feel free to do so (both trying and believing :-).
Just some more bits to consider:
1) Several things will look painfully ugly with the new look. Sliders with
a customized handle for instance, since the ones in existing applications
are written to look good in R5. The same holds for custom controls. Then
there's the hell of hardcoded colors.
2) You probably want to change the look live. Ever though about how to
accomplish that? Probably not that difficult, but again some more work...
CU, Ingo
Other related posts:
