unity-design team mailing list archive
Mailing list archive
Re: Unity extensibility. Was: complaints
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 "