On 30/12/10 01:53, kfsone wrote:
> In the desktop arena, I would implore you attempt to reconcile any such
> design decisions with the root of Ubuntu's success, which is the quality
> of desktop experience it delivers out of the box. "It's open source, fix
> it yourself" is what I expect to hear from Gentoo, not Ubuntu. "Switch
> to a different desktop experience" is something I expect to hear from a
> Ubuntu derivative or a lesser Linux entirely.

A willingness to limit the set of supported options is a large part of
the quality of the out-of-box desktop experience. For example, the old
Gnome Panel was designed with the goal of making many, many things
possible. you could put them on any edge of the screen, you could write
any sort of app, that supported any sort of interface pattern. And the
result was very, very hard to use well. All of that customization made
it impossible to provide an "overall feeling" to the old Gnome Panel.

And this is similar.

Now, I know full well that the argument for being "on rails" can be
taken too far. It boils down to a judgement call, which has to be made
in the knowledge that wherever one draws the line (or *I* draw the line,
if you want to be personal about it) there will be some folks who never
use the flexibility offered, for whom it's confusing, and others for
whom it's not enough and who resent the line having been drawn there.

In all cases, it's not unreasonable to ask folks who want something
badly to implement at least a hacked up version of that capability. I
don't think it's needed, and I think it could in fact be detrimental
both to the user experience and the code itself, so I'm simply not going
to ask Canonical folks to spend any time on it. But I can't stop, and
have no interest in stopping, someone from working up a patch which
implements the capability, which can then be tested and discussed.
Bleating or sulking don't inspire me to spend time and money helping out ;-)

So, "work up a patch" is a reasonable statement. "Use a different
interface" is also a reasonable statement. That's not "we don't care
about you" it's "we are busy implementing a particular vision". We may
be wrong, the best way to learn is to have others show that a better way
is possible. If so, we'll adapt quickly, we're not too proud to embrace
great work done elsewhere.

> Let me close with some practical use cases:
>
> 1. RTL countries,

Yes. But this involves mirroring everything: launcher, panel,
indicators, window controls. It's not an argument for being able to
place the launcher anywhere, it's an argument for a proper RTL
perspective on the shell. That is being tracked in a separate bug, iirc.

> 2. Portrait displays (where the vertical launch bar has the opposite of it's intended effect),

At this stage, our view is that intellihide makes the launcher position
acceptable on portrait interfaces.

> 3. Left-handed mousers,

There's no strong argument that a left-handed mouser benefits from the
launcher being anywhere different. One needs to be able to get to any
point of the screen with a mouse for it to be useful :-) And touch
interfaces, arguably, are better for lefties with the launcher in its
current position.

> 4. Accessibility conflicts with left-of-window controls in applications (esp web-browsing where navigation is frequently on the left-side, whereas the scroll bar serves as a buffer for them between pages with right-hand navigation and a right-handed launch bar).

Don't count on that buffer indefinitely ;-)

The launcher should typically not be visible when you're surfing the
web. It's there when you invoke it, then it goes away again. We've
deliberately not made the launcher appear when you touch the left edge,
to avoid tension between left-page-nav and the launcher. To invoke the
launcher, you have to hit the corner of the screen.

> 5. Accessibility issues where the user's primary use of the computer is centered around the right hand side of the screen,

Such as?

> 6. Multi-screen displays where the left-most display is the minor display, and having the launch bar on the left side of the primary screen is a bloody nuisance.

True, we need to do some iterations on the multi-screen story.

Mark