GNOME Bugzilla – Bug 104686
Menu Panel 's chooser button should be able to access a task's window menu
Last modified: 2018-01-24 13:21:15 UTC
Description of Problem: The task chooser button at the far-right of a Menu Panel should be able to access a task's window menu (just like right-clicking the task in the window list applet). This will allow users to close a number of open applications back to back using just the chooser button. This will also give users the choice to simply not use the window list applet (and save panel space) but retain its functionality.
Allowing the pull-down menu to serve as a functional replacement for the window list seems like a pretty good idea. As people have mentioned on the lists, there are downsides to using a right click inside menus, though I don't think I mind this so much.
There is a relevant discussion about this feature enhancement starting on bug # 87831 comment #2
The Window Selector now uses the new WnckSelector widget from libwnck. Moving bugs to libwnck.
*** Bug 165268 has been marked as a duplicate of this bug. ***
Created attachment 36572 [details] what it looks like I played around with selector.c, testing it with the test-selector from bug 165269. Here's what it looks like. The behaviour of the window selector menu is to stay there while the user uses action menus. The problem is that it stays displayed when the user clicks off the menus.
Created attachment 36573 [details] [review] patch to get action-menu on third button click This catches a button_press event and displays an action-menu if it's a third button click.
Created attachment 36574 [details] [review] better patch to get action-menu on third button click hack of attachment 36573 [details] [review] to popdown the selector on window action menu deactivation.
That's neat, and it works well. Small bug though : the applet button still appears selected after acting on a window. To reopen the menu you have to click once to deselect it, and twice to reselect it.
Actually, I kinda like the way the first patch worked. The window menu stayed up after acting on the window. That way, you can minimize a few applications in a row. But I don't know what the best choice is. About the patch : * why use a g_signal_connect_object when g_signal_connect works fine ? * to correctly close the menu (if that's the way we want it), in wnck_selector_popup_menu find the parent of the select GtkMenuItem (with a gtk_widget_get_parent). The parent is a GtkMenu, that descends from a GtkMenuShell, meaning you can do this : item_parent = gtk_widget_get_parent (GTK_WIDGET(item)); g_signal_connect_swapped (G_OBJECT (menu), "deactivate", G_CALLBACK (gtk_menu_shell_deactivate), item_parent); And it will work.
I'm still not that familiar with the API. Thanks a lot for your suggestion tho'. I think I like the first behaviour (the selector staying up while I close/minimize/etc. applications). It's annoying to have to repeat opening the applet for each window.
Created attachment 36632 [details] [review] better patch to get action-menu on third button click patch to get the second behaviour using gtk_widget_get_parent()
Should this work with the keyboard too, with Shift+F10?
I guess so :-( Also it would be nice if once you have the window menu up, menu items for other windows (ie items in the WnckSelector menu) would not highlight. In other words - once the window menu is up, the WnckSelector menu should not change state (am I being confused here or is it just me ?)
Moving to the right component. Sorry for the spam.
I'm not sure I get highlight behaviour you are talking about. The only thing I see related to highlight, is that the current WnckSelector menu item looses it's highlight when the window-action-menu (contextual menu) pops up. None of the WnckSelector menu items get highlighted when I hover over them with the mouse. Maybe we'd want to keep the current selector menu item highlighted.
Created attachment 36690 [details] [review] action-menu on third button click and menu key press This patch is to get the action-menu on third-button click and menu-key press. It's an improvement on attachment 36573 [details] [review]. It's a copycat of the contextual menu for items in the panel's menu ("Add this launcher to the panel", etc.). The Selector stays on action or deactivation of the action-menu. If this behaviour is good enough for the panel's menu, let's stick with it for consistency. What do you think?
Created attachment 36692 [details] [review] action-menu on third button click and menu key press updated to match CVS HEAD.
Denis : This last patch is nice, however you miss two includes : #include <gdk/gdkkeysyms.h> #include "window-action-menu.h" Still I get the same bug as previously : other windows menu items are highlighted. It's as if I had two active menus at the same time. Not a big deal, though. Could someone with more power than me comment on the patch ? :)
Created attachment 36793 [details] [review] action-menu on third button click and menu key press Vincent: Thanks for the help and fixes. I really don't get the problem you do tho', the selector items cannot highlight while the context action menu is displayed. How does the gnome-panel menu behave with context menus for you? Does the same highlight problem occur?
I'd say this breaks feature freeze... (I haven't look at the patch yet)
Created attachment 38512 [details] [review] action-menu on third button click and menu key press (updated for 2.10) the patch now works for 2.10
Hi, could we test this before the next feature freeze if that's ok?
Okay, we suck. Sorry for taking so long to get to this and missing feature freeze. I guess I wasn't very successful at shoving this off onto the other libwnck maintainers... Anyway: - I get the same highlight problem that Vincent (Noel) does. To reproduce for me: Left click on wnck selector applet, right click on one of the menu items that appears, move the mouse around over. If the mouse is over the raised right click menu then those items get highlighted, while if it's over the wnck selector's original menu then those items get highlighted. - I think that it would help the user keep track of what window they are acting on if the window for which the right click menu has been open remains highlighted. - The Roll Up item will probably be removed in order to sync with the metacity menus (bug 135710; though personally I'd prefer long-term if we came up with some protocol to just have Metacity show the menu for libwnck to avoid having the same code in three different places)
Actually, I just noticed that I can get the highlight problem with the tasklist too, so I don't think that issue is such a big deal. However, if your mouse is nowhere near the selector and the user presses shift+f10 the window still appears where the mouse is which seems very weird.
Can we include this in the code? I'd rather have the feature and fix the window-near-mouse bug as we go along.
If we include the feature without the fix, then it likely won't get fixed. Also, I tested again; more issues - When I used Shift+F10 and get the little popup near the mouse and select something like minimize, it doesn't appear to work. Maybe a different window was minimized or something? I don't know. I tried repeating and selecting close and saw some kind of shuffling occur in the selector's menu, but it wasn't the window that was highlighted. - After doing the above, I tried yet again, and got a crash. It appears that something other than a WnckWindow made it to wnck_selector_key_press_event() for the data parameter. I'll attach the stack trace that I got.
Created attachment 53240 [details] Crash while using the patch
Created attachment 88405 [details] [review] Updated patch I updated the patch to trunk and fix the issue Elijah reported with Shift+F10. There are three (minor) issues left: + if you use test-selector to test this feature and if you close the right-click menu by clicking outside of it, the mouse cursor becomes a "resize" cursor. I'd say this is a metacity bug, though. + if you use test-selector, you don't get the highlight moving on the selector menu, but if you use the applet, you get it. The weird thing is that the panel uses the same code for the context menu in the application menu, and it works... + if you open the context menu with the right-click and close it by clicking outside of the menu, then the selector menu stays opened. If you do the same thing, but opening the context menu with Shift+F10, then the selector menu is closed. I don't consider the "menu appears where the pointer is when using Shift+F10" thing a bug, since this is what happens by default in GTK+ when you use Shift+F10.
I tried the patch with libwnck 2.19.2 and gnome-panel starts and dies a couple of times before giving up. test-selector worked with the patch when I tried it last week, but today it segfaults.
Weird. It works fine here (except the issues I already listed).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libwnck/issues/22.