On Fri, Apr 29, 2011 at 3:58 PM, Toki Tahmid <
oxwivi@xxxxxxxxx> wrote:
> 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
>
>
> _______________________________________________
> Mailing list:
https://launchpad.net/~ayatana
> Post to :
ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe :
https://launchpad.net/~ayatana
> More help :
https://help.launchpad.net/ListHelp
>
>
_______________________________________________
Mailing list:
https://launchpad.net/~ayatana
Post to :
ayatana@xxxxxxxxxxxxxxxxxxx
Unsubscribe :
https://launchpad.net/~ayatana
More help :
https://help.launchpad.net/ListHelp