← Back to team overview

unity-design team 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 "


Follow ups