[openbeos] Re: Visual design stuff again

  • From: "Simon Taylor" <simontaylor1@xxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sat, 27 Sep 2003 21:01:12 +0100 BST

> > 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 do think there is a difference between having a public skinning API 
where user skins abound, and having one new UI with the option of 
switching back to the old one.

I do completely agree that it is not really the Right Way (TM). 
However, I think it is acceptable given the stages gone through:
1) No new major "features" in R1
2) That means no public skinning API
3) Does that mean we are stuck with the R5 look?
4) No, none of the other parts of the project are constrained by the R5 
*implentation*, just by the API
5) Therefore we can just change the implementation of the Draw() method
6) But hang on, some people might not like it
7) OK then, so we'll keep both implementations and allow the user to 


> > 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...

Marc has already put work into the current implementation, that would 
need changing to switch to skinning - this would just be improving 
(IMHO) on an already short-term implementation - I don't see anything 
wrong with that.

Also I'd like to see the discussion on GE where it was agreed that OBOS 
would have a full skinning implementation in the next release.

> > 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.

Yes I'm aware of all that. My response is that I assume the look will 
be changed at some point - better to do it in R1 so that developers get 
a chance to fix their code (use ui_color or whatever) before a release 
that really brings in the users (R2). I've found some early BeOS 
screenshots (DR8 I think) and it's amazing how little has changed to 
R5. I would argue that something similar would happen with OBOS - if 
there was an updated look in R1, R2 would probably look fairly similar 
to that - meaning both that the "product" has an identifiable image 
throughout it's development, and that any visual apps written for R1 
will look OK in R2. 
> 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...
I have thought about it, but dismissed it as not 100% possible without 
API changes. Mainly because of colors - if the new look has different 
system colors, normal BViews that were just set on construction with 
SetViewColor(ui_color(B_PANEL_BACKGROUND_COLOR)); wouldn't switch.

The same thing happens in R5 if you try to change the menu font - it 
doesn't happen live and that really annoys me. At least putting the 
option in a boot script means users won't expect it to happen live. I 
think most users will stick with the new look, but old R5-lovers will 
switch once, and only once. It's not going to be the kind of option 
people are going to change on every session. Therefore, again it's 
"acceptable" (not the Best Way) to have the change controlled by an 
environment variable in a boot script.

> CU, Ingo


Other related posts: