I like the idea, but we need some sort of suggestive button so that new users can tell that it's related to the menu. But I think mouse over would be better than a click. And I very much support the idea of left alignment for all the menus (maximised or otherwise).
On 29 April 2011 19:03, Ed Lin <edlin...@gmail.com> wrote: > There are several problems with this: > > Drag-click on a menu: on current menus, even with the firefox button > one can press the mouse, the menu appears, move the mouse over desired > entry, release. This is quicker than click, move, click again. > Even if you don't do that, this is a very common user case: you try to > hit a menu entry (top level i.e. File, Edit..) only to realize you > missed, you don't release yet but simple move the presses cursor over > the correct entry. This can't be discerned from a horizontal title-bar > drag. > > Second problem: this will result in flickering or a lot of GUI noise > so to speak. This isn't only an aesthetic issue. > > Third: people still don't know when to use single and when to use > double-click. They'll try to double click on a menu only to end up > maximizing the window. > > How would you like this? > Put a single menu button into the titlebar, right upper corner would > be free but the left side would be better. I'd probably favor one on > the left of the toolbar/tabbar/whaterver below. Click it once and a > horizontal menubar appears temporarily between the tool/tab/*bar and > the title bar, click it twice and it stays. > > On Fri, Apr 29, 2011 at 3:58 PM, Toki Tahmid <oxw...@gmail.com> 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 <aaaanto...@gmail.com> wrote: > >> > >> On Fri, Apr 29, 2011 at 9:12 AM, Toki Tahmid <oxw...@gmail.com> 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@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~ayatana > >> More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~ayatana > > Post to : ayatana@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~ayatana > > More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~ayatana > Post to : ayatana@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ayatana > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
