unity-design team mailing list archive

[Toki Tahmid <oxwivi@xxxxxxxxx>]

In case of C, a double-click is usually too fast for anything to show.

I'm against the idea of wrapping to a new line, it won't look good and if
the first menu was accidentally invoked, it'd add to the hassle to have to
close it and then select the menu in the second row.

On 29 April 2011 17:48, Anthony Scire <aaaantoine@xxxxxxxxx> wrote:

> On Fri, Apr 29, 2011 at 9:12 AM, Toki Tahmid <oxwivi@xxxxxxxxx> wrote:
> > @Ed, thank you for the lengthy explanation to Fitts' Law.
> >
> > That was a mistake, I meant to say horizontally, didn't notice till now.
> > Anyway, as I mentioned multiple times on other message threads, I suggest
> > the placement of menu on title bars of the windows. Unlike the current
> menu,
> > it shouldn't be completely hidden, but slightly faded which would fade in
> on
> > mouse over. IMO, this way will be functionally and aesthetically better.
> > Windows which currently open small could be wider be default to
> accommodate
> > the menus, and allow some sort of scrolling if deliberately made smaller.
> I
> > won't deny that this idea does pose a problem of dragging, but despite
> not
> > coming up with a suitable solution*, I still want to push forward with
> > menu-on-title-bar.
>
> There are two actions I expect from a title bar.
> 1. Click and drag to move.
> 2. Double-click to maximize.
>
> (Also, I guess right-clicking for advanced options is nice, too.)
>
> Anyway, I don't see why a menu bar built into the title bar -- in the
> way that you suggest -- should interfere with any of these actions.
> Consider the following use cases.
>
> A. User wants to access one of the drop down menus via mouse.
> 1. User spots partially concealed drop-down menu title in the window's
> title bar.
> 2. User moves the cursor to the drop-down menu.
> 3. User clicks.  The menu expands when the click is released.
> 4. User moves the cursor down into the menu and looks for whatever
> function he has in mind... and so forth.
>
> B. User wants to move the window via mouse.
> 1. User moves the mouse cursor to the title bar.
> 2. User clicks and drags.  The window moves.
> 3. User releases the mouse.  If the window was moved more than -- say
> -- a few pixels from its original spot, or if the mouse button was
> held down for longer than 2 seconds, then the menu will not expand.
>
> C. User wants to maximize by hitting the much larger target (Title
> Bar) rather than the tiny window control (the Maximize button).
> 1. User moves the mouse cursor to the title bar.
> 2. User clicks a first time. On release, the menu expands as described
> in Use Case A.
> 3. User clicks a second time, as the second half of the double-click.
> The menu closes (as a second click on the menu is expected to do), and
> the window maximizes.
>
> I'm sure some accessibility issues will arise from this, but my point
> is that this should be possible.
>
> If the menu bar extends beyond the width of the window, it should wrap
> to a new line.  Which, in effect, will make the title bar larger.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>