Menu Panel 's chooser button should be able to access a task's window menu

Submitted by Riandi Wiguna

Link to original bug (#104686)

Description

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.

Seth Nickell said:

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.

Denis Jacquerye said:

There is a relevant discussion about this feature enhancement starting on bug # 87831 comment 2

Vincent Untz said:

The Window Selector now uses the new WnckSelector widget from libwnck. Moving bugs to libwnck.

Vincent Noel closed a related bug:

*** Bug 165268 has been marked as a duplicate of this bug. ***

Denis Jacquerye uploaded an attachment:

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.

Attachment 36572, "what it looks like":

Denis Jacquerye submitted a patch:

This catches a button_press event and displays an action-menu if it's a third button click.

Patch 36573, "patch to get action-menu on third button click":
window-selector-action-menu1.patch

Denis Jacquerye submitted a patch:

hack of attachment 36573 to popdown the selector on window action menu deactivation.

Patch 36574, "better patch to get action-menu on third button click":
window-selector-action-menu2.patch

Vincent Noel said:

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.

Vincent Noel said:

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.

Denis Jacquerye said:

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.

Denis Jacquerye submitted a patch:

patch to get the second behaviour using gtk_widget_get_parent()

Patch 36632, "better patch to get action-menu on third button click":
window-selector-action-menu2.patch

Denis Jacquerye said:

Should this work with the keyboard too, with Shift+F10?

Vincent Noel said:

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 ?)

Vincent Noel said:

Moving to the right component. Sorry for the spam.

Denis Jacquerye said:

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.

Denis Jacquerye submitted a patch:

This patch is to get the action-menu on third-button click and menu-key press. It's an improvement on attachment 36573.

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?

Patch 36690, "action-menu on third button click and menu key press":
selector-action-menu-behaviour1.patch

Denis Jacquerye submitted a patch:

updated to match CVS HEAD.

Patch 36692, "action-menu on third button click and menu key press":
selector-action-menu-behaviour1.patch

Vincent Noel said:

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 ? :)

Denis Jacquerye submitted a patch:

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?

Patch 36793, "action-menu on third button click and menu key press":
selector-action-menu-behaviour1.patch

Vincent Untz said:

I'd say this breaks feature freeze... (I haven't look at the patch yet)