[openbeos] Re: Visual Design for R1?

  • From: "Simon Taylor" <simontaylor1@xxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Fri, 26 Sep 2003 10:08:55 +0100 BST

> Simon Taylor wrote:
> > Thanks very much. Heh - looking at those mock-ups, I think ppl 
> > would be 
> > crazy to switch to anything other than the default ;) 
> > 
> > What do the ppl responsible for the actual controls (Erik/Mark?) 
> > think 
> > about a redesign of these components?
> I've commented on this before, but I guess it bears repeating.  At 
> this 
> point, we will *not* be redoing the controls.  A lot of work has been 
> put in getting them where they are and there are lots of other tasks 
> that are far more important to actually getting a shipping OS.  If we 
> get to R1 and it seems a *terribly* pressing issue, we can take up 
> the 
> debate then.  If it is truly important enough, we'll delay the 
> release. 
>   I imagine given the choice between "release now" and "delay for 
> widget 
> makeover", people will overwhelmingly choose in favor of "release 
> now". 
>   The key thing to remember is that doing it now would cause the same 
> delay -- easier to overlook since it would be happening in the middle 
> of 
> so much other work, but still there.

The balance that has to be judged is whether the time spent will give a 
significant return. If the new look encourages one more person to 
download, who likes what he sees, and then becomes a full-time 
developer for R2.

Even I, thinking of myself, would vote in favour of "release now". But 
that is because I am already very keen on the project, I know the huge 
amount of truly great work that has been done already, and I can't wait 
to use it. It's for reasons of attracting others, and attracting back 
ex-BeOS users, that I would vote for a widget makeover.

Another point is there is no rule that says the first complete binary 
compatible release has to be called "R1" - only when you are happy with 
it as the first real milestone release the project will be judged on, 
should an "R1" be released.

> A side note:  You mentioned the use of "gradients" in the BeOS window 
> tabs.  Those aren't gradients, per se; they're drawn to look like 
> they 
> are.  That is to say, there is no "DrawGradient()" call hiding 
> somewhere 
> in app_server that we could just expose (or even use behind the 
> scenes). 
>   And that's fine for window tab elements whose size never changes.  
> But 
> for controls, whose size can change at any time, it's a whole 
> different 
> ball of wax.  You'll end up having to create that gradient-drawing 
> API 
> (after all, buttons aren't the only place you want them, yeah?) and 
> that 
> needs to be done correctly.  It's exactly the sort of thing we want 
> to 
> do for R2 -- and exactly the sort of thing that will have to wait 
> until 
> then.

AFAIK, there aren't many (any?) variable-sized gradients that need 
drawing. Scroll bars are a fixed width, tabs are a fixed height, etc.
> If you really have time to spend recoding the drawing routines for 
> all 
> the controls, please spend it working on things that have not already 
> been written.  You don't have to be a wiz to write unit tests, for 
> instance. =)

I'll think about it. I've never done anything with unit tests before, 
but I'll have a look at some of the existing ones.

Given the choice between writing a few hundred lines of code that will 
completely alter how R1 is perceived by the world, or (the undoubtably 
important job of) writing the same amount of code to test an internal 
part of the OS, I'd rather go for option 1.
> Believe me when I say I'm no enemy of aesthetics -- BeOS' clean, 
> sharp 
> look was what initially drew my eye when I first saw a screen shot in 
> Electronic Musician back in 1995.  And there's little doubt that this 
> look has aged a bit.  Nevertheless, I'm going to be pretty peeved if 
> working, tested code gets monkeyed with just to sex up the widgets a 
> bit.  Let's just get this thing out the door, and then we can all 
> have a 
> grand old time extending our favorite OS.

Fair enough. As I've said before, getting it out the door and releasing 
R1 are not necessarily the same event.

The fact that the code is under an MIT license means, of course, that I 
can do what I want. I've got a complete OBOS tree on my HDD, Stuart is 
sending me some high quality images of his designs next week, and I'm 
going to have a go at coding them.

If it is impossible with the current drawing API or if it requires 
sweeping code changes, I'll drop the whole thing, and you'll suddenly 
notice me go very quiet :-)

However, if I manage to implement a new look, with a method of keeping 
the current code and switching back to an R5 appearance if so desired, 
would it be rejected?

I apologise to everyone for hijacking the list for a non-OBOS-
developmental topic. Unless there are some responses that I can't 
resist replying to, this will be my last post on the topic.

If any of it seemed like I was criticising the project, none of that 
was intended. I have nothing but awe and respect for all those working 
so hard to keep the dream alive, and to secure a future for a BeOS-type 
platform. The reason I raised the issue is that I want to see all the 
hard work you have done properly recognised by the outside world when 
R1 is released.

Keep up the great work.

Other related posts: