Inconsistent click actions on new locally integrated menus (LIM)

[asmoore82]

This is related to Bug #1283849 and all of its duplicates.

As those say, middle click to lower windows is now broken. But I feel that right clicking here is just as bad or worse. Right clicking still presents the classic window actions menu which is entirely expected by crufty old desktop veterans but Unity is *not* supposed to be another crufty old desktop :P. The indicators broke new ground with left and right clicking both presenting the same consistent menus and I feel that the new LIM should do the same. Note here that middle click on LIM already does the same action as left click, so why not right click too? All of this "click convergence" eases some user confusion and greatly eases the pain of touch screen devices that are more than tablets but less than laptops.

So what about this lost "lower" functionality? First of all, it always *should* have been a part of the standard window menu so let's go ahead and have it in there. Secondly, if right click does not expose this menu because of LIM/Indicator consistency, then let's just go ahead and bring back the window menu as a standard part of every window decoration. I'm thinking it will replace/obsolete the always visible minimize/maximize buttons and will integrate seamlessly with LIM such that opening the window menu and then mousing right will move right on to "File, Edit, View, etc."

This would add a further layer of consistency for windows that do not support resizing or maximizing. As is, the dedicated maximize button on them can be taken away leading to slight inconsistency in window decoration, but with a window menu instead it will always be there and will simply have the options inside greyed if the window does not support them.

If Bug #1283849 is flatly fixed it sort of obsoletes this bug but it is not exactly a duplicate either :D.

[asmoore82 (asmoore82)]

I usually don't like the "Other OS does X" comments but here I go...

This is somewhat more relevant than "Other OS does X" because you can see this behavior within Unity if you test it out by blacklisting some programs from unity-gtk (I checked gnome-terminal, eog, gvim). I guess they are "vanilla" GTK menus but they are completely click agnostic. Left, Middle, and Right Click all have the same effect in menus until they are taken over by Unity. Actually I just double-checked with LIM disabled and Unity Global Menus behaved the GTK way too. Honestly, I didn't even know this was the case until now.

This brings up another menu behavior that is lost in LIM. This may need a bug report with design decision in its own right but I think that pretty much all FOSS menus have traditionally supported the click and hold behavior and now LIM does not. For example, in Firefox even when maximized with LIM off you can click and hold "Edit" and then mouse down to hover over "Preferences" and then release the click to open Preferences. But with LIM on, this immediately initiates a window move operation instead.

I'm not terribly affected by this and I do much prefer LIM's placement to all other options, but I'm long-winded on this issue because I hope for us all to have thoroughly informed and discussed design decisions to point to when the complaints inevitably roll in from one group of users or another.

[asmoore82 (asmoore82)]

Every once in a while, I catch myself using the click and release menu style instead of multiple clicks. Just now I stumbled upon the "smoking gun" that really pushes the lack of click and release in LIM into buggy territory. The indicators do support click and release. So when you have LIM and a maximized window, you get the application menus and the indicator menus practically side by side and one will do click and release but the other will not.