GNOME Bugzilla – Bug 132156
cannot detect presence of context menus
Last modified: 2010-07-06 21:08:55 UTC
it seems that we don't ever see an 'action' for popping up a context menu. I think we agreed previously that this was the heuristic for determining that a context menu exists for an object. For instance we can't tell that the nautilus 'desktop' has a context (right-click) menu, and therefore cannot expose it in GOK. if this is a nautilus bug please transfer, but I suspect that this may be at least partly addressable in gail for some widgets. Padraig?
It seems that you asking that the AtkObject for a GtkWidget, or even a non-widget, be aware of whether Shift+F10, the keybinding for popping up a context menu actually pops up a context menu? I do not think that this is possible.
we already agreed that this was necessary however. I agree that we may not be able to detect it in the general case but we do need to expose it on 'standard' components for which context menus are expected. besides, can we not detect whether a signal handler for the corresponding signal is attached? It's required for nautilus at least.
Sometimes instead of defining a signal handler for popup_menu signal a a key press event handler which checks for Shift+F10 is used. What are the 'standard' components for which context menus are expected. I have looked at the implementation of NautilusIconCanvasItem and it does have code to implement an action called "menu". This should work for icons on the desktop. I need to look at the accessible implementation for the desktop.
ok, if the keypress handler is used then we probably can't do a lot to detect it. Perhaps we should recommend against that implementation. I didn't see the 'menu' actions on the icons in at-poke, will look again.
The menu action is there for icon. You need to scroll down to see it. The menu action requires that the icon be the only one selected in order to work.
Transferring nautilus/Accessibility
Created attachment 23664 [details] [review] Proposed patch
The proposed patch adds menu AtkAction to desktop and Icon View.
Bill, Can you confirm that this patch fixes the problem you reported.
Updating status whiteboard to reflect a11y team's assessment of priority.
Padraig, any chance of implementing this for vte as well?
If you open a bug against vte I will have a look at it.
Hi Padraig: the patch does work; however there's the issue of focus-on-desktop-icon vs. focus-on-desktop to contend with. It seems that from our perspective focus is pretty much always on the selected desktop icon, which means that the icon context menu is easy to find (i.e currently-focussed-object has context menu heuristic) but the desktop's context menu is a little harder. I'm still thinking about that topic to see if there's a logical solution to offering 'both' context menus (e.g. Control-F10 and Shift-F10 equivalents).
Patch committed to CVS HEAD.
Changing component as a part of ongoing reorganisation work.