GNOME Bugzilla – Bug 116028
panel applet context menus should appear at the mouse cursor not below the panel
Last modified: 2015-03-24 13:00:49 UTC
Context menus for panel applets should appear at the mouse cursor position not below the panel like all other context menus. The current behavior makes using the context menu harder because the user needs to move the mouse to the menu and hence requires more precision to select the first menu entry as oppose to be able to simply click and release the mouse button to select the first entry in the menu as in all other context menus in gtk.
Created attachment 30428 [details] [review] Proposed patch.
Calum, Byran, Seth (and whoever else is on usability-maint): what do you guys think? We've deliberately been doing it it the way it is now and changing it to the way Dave suggests is just a matter of removing code.
I guess I should just apply the patch and see what the difference is, but I'm not entirely sure I understand the proposed solution from its description :/ A screenshot of the new behaviour might be helpful. Also bear in mind that any context menu that appears under the mouse pointer must only do so when activated from the mouse itself-- keyboard users need it to appear over or near the focused object when they press Ctrl-F10. The mouse pointer could be on a completely different screen, or at least nowhere near where the user is working.
Er, I mean Shift-F10. (Although in the case of the panel, Ctrl-F10 too.)
Created attachment 30712 [details] This is the current behavior
Created attachment 30713 [details] This is the patched behavior
I was in the panel code already (don't ask why) and had an extra second. This patch actually doesn't effect the panel applets like was discussed in the bug report but it effect the launchers. Applets still popup menus below the panel even with this patch. I think the idea might have merit for thicker panels than mine. Having a panel be 24 pixels thick means there's no real advantage to this system, a savings of a couple pixels of moving. However for 48 pixel panels I could see how it _might_ be an improvement in showing a popup menu nearer to the click. Guess I'll have to do some testing first. One thing I have found right away is that if I click on the wrong object by accident the patched method can cover up the object I was intending to click on (like the totem or evo launcher in the sshot). Though this probably isn't a horrible thing since I have to right-click twice no matter what to get the context menu on the correct object. (i.e. once somewhere else, then once on the correct launcher OR once on the correct launcher and once again to actually get the popup)
> This patch actually doesn't effect the panel applets like was discussed in > the bug report but it effect the launchers. Applets still popup menus below > the panel even with this patch. Bryan: It effects launchers and (should at least effect) applets when it comes to popup menus handled by the applet popup component. If applets create menus using gtk_menu_popup and pass a custom menu position func (wncklet/window menu does so), that's their problem. regs, Chris
Comment on attachment 30428 [details] [review] Proposed patch. Marking the patch as "needs-work", but what we really need here is a decision on whether we want to keep to the current behaviour or just let the menu popup at the pointer position. Manny's patch looks fine to me if we want to go with the latter.
Any decision on this?
It's horribly irritating when I right-click on my looong workspace selector applet. I've got 8 desktops showing their names, which makes it take up 50% of the screen width. Whenever I right-click, the menu pops up at the far left, and I have to move a long way to reach it. </rant>
bug 136722 comments on how the inconsistency between placements is an issue. We should decide on one. I think I've always leaned toward the current behavior because I think that a mis-click on the wrong an applet allows a context menu to cover up other applets that you might have meant to click on. Maybe that's not the best rationalization but it happened to me a couple times in the testing of the patch.
I tried the patch and found the behaviour irritating. So I'd be with Bryan on this one. However, we can solve Vidar's problem. Here's my proposition (~ current behaviour): * do not show the menu where the mouse pointer is, but below the panel * the menu should be vertical aligned with the mouse pointer (for horizontal panels; for vertical panels, it should be horizontal aligned).
Sounds like a great idea, I think that would address all the concerns about this.
Sorry for the spam. Mass-marking some bugs to the 2.10.x milestone. Filter on "VINCENT WANTS THIS FOR 2.10" to ignore.
I committed the following stuff. Guys, could you try it and tell me what you think? If it feels weird, please reopen the bug. What's interesting is testing the algorithm on applets that are at least twice as large as the context menu width. 2005-01-12 Vincent Untz <vincent@vuntz.net> Try to make the menu position algorithm better. Fix bug #116028 * panel-applet.c: (panel_applet_position_menu): position the menu left-aligned at the left of the applet if the mouse pointer can reach it without moving or right-aligned at the right of the applet (if the mouse...) or aligned with the mouse pointer. Sounds complex but try it and you'll understand :-)
Could this fix be applied to the tasklist too ? See bug #92842