unity-design team mailing list archive

[Petko <pditchev@xxxxxxxxx>]

On 02/09/2012 06:58 PM, Jo-Erlend Schinstad wrote:
> Come on. Comparing a nearly invisible feature to cutting off someones 
> limbs? That's not even rational. If you want to contribute, why can't 
> you instead explain what's so important about the dodge?
Here, I'll explain - with always visible the launcher takes space (for 
some people too much) .
With auto hide :
1. There is a blank line on the desktop where the launcher should be 
(you cant put icons there)
>being on the desktop usually implies that you'll start some app , so 
it's most logical to have the launcher open
2. It's handy to have the launcher open as much as possible , which is 
what exactly the dodge windows did .

> No, actually, that is two fairly radically different things. 
> Applications are separate entities. GCalctool is not disturbed by the 
> fact that there might be other calculators out there. Features in a 
> program are usually not very separate. For example, I can write a 
> fifty page reply to you now. After all, other readers might have 
> questions that you didn't ask, but that they would theoretically want 
> an answer to. Should I put in all those answers (features) just in 
> case, or should I keep it brief and comprehensible? The exact same 
> effect applies when the text you're reading is source code. More code 
> nearly always means more bugs. It always means more to process, which 
> means slower software. It is also always more difficult to maintain, 
> which means less effort goes to real development.

Here we're talking about making the optimal solution . Keeping some 
useful (and as far as I know) stable code in the code base is a good 
thing (when it's not all of the legacy code , but some portion of it ) . 
We had 4 behaviours , I think reducing them to two and keeping 3 for 
advanced use in the code base is an optimal solution. I'm giving so much 
attention to the subject because it is somewhat universal . Here's a few 
points to having things this way ,as I wrote them  elsewhere:

"Here's the four points to keeping such resources :

-they might appear more usable further down the road
-they will be available for advanced customisation and/or experimentation
-they generally don't need maintenance
-they don't interfere with "keeping the code clean" . The code base 
isn't an interface , and having a rich code base , if it's stable ,can 
only be a plus for a developing component "

Petko