GNOME Bugzilla – Bug 774890
"Keyboard shortcuts" dialog does not show all actions
Last modified: 2018-05-24 17:11:30 UTC
So I noticed that the "Keyboard shortcuts" dialog does not list all available actions. This is because we only display action groups from the GimpUIManager "<Image>". Various groups, like "palettes-*" actions for instance were not available. I have just fixed this for the action search, which had the same problem. But I wonder if for some weird reason, this was intended for the shortcuts dialog? If you tell me this was not intended, I will just fix this. It's easy. P.S.: these actions are still available and shortcuts settable by editing menurc. They are only absent from the GUI.
Yes this was intended so it only shows the actions that make sense in a "global" (== image) context. It seems for the price of missing some actions. We have some pretty absurd action groups that should probably not be searched. Also, the actions of the global <Image> manager have the right sensitivity, while the actions of the other UI managers (like for individual dockables) are only updated before the respective menu is shown.
I see. Well in this case, I guess the fix would be to check if we cannot also store some action groups into the <Image> UI manager as well. I'll have a look.
I think that all (most?) groups that make sense are in the <Image> UI manager, you can check in menus/menus.c. It looks like the only things "missing" are the entries for brushes, patterns etc that probably only make sense in the context of their dialogs, and some of them expect the actual dialog widget as user data in the callbacks. While it might make sense to also search the brushes, patterns etc. actions, I think we definitely don't want the actions of e.g. the gradient editor which work on the editor's selection. Maybe it's most sane to roll back that patch, and instead explicitly look up the UI managers for <Brushes>, <Patterns> etc. separately? Also, you must not include menus/ stuff from widgets/ anyway, only the other way around.
> Maybe it's most sane to roll back that patch, and instead explicitly look up the UI managers for <Brushes>, <Patterns> etc. separately? Hmm… ok. Why not. I'll do it this way then. > Also, you must not include menus/ stuff from widgets/ anyway, only the other way around. When I'm not sure, I always make a grep first to check if there are precedent. And I found a few include of menus/ from widgets/ (and not by me!), which was why I went ahead with it. :P So there may be things to fix then. ;-)
(In reply to Jehan from comment #4) > Hmm… ok. Why not. I'll do it this way then. Or a better way, if you come up with one :) > > Also, you must not include menus/ stuff from widgets/ anyway, only > the other way around. > > When I'm not sure, I always make a grep first to check if there are > precedent. And I found a few include of menus/ from widgets/ (and not by > me!), which was why I went ahead with it. :P > So there may be things to fix then. ;-) OMG indeed, we apparently lack some abstraction there and instead we (probably I) included from menus/ anyway ;)
Thinking again, that entire change is unfortunately wrong, the only right UI manager is in fact gimp_ui_managers_from_name ("<Image>")->data because it's the global popup <Image> UI manager which is independent of a display and it always in the right state for the currently active image, all other UI managers are wrong.
Sorry, additionally, it was preventing invokation of plug-ins and GEGL ops: commit 6131b00b54d03268ce094dadb69990a9130c6096 Author: Michael Natterer <mitch@gimp.org> Date: Thu Nov 24 21:08:34 2016 +0100 Bug 774890 - "Keyboard shortcuts" dialog does not show all actions Revert "app: action search should search accross all available actions." This reverts commit 53b3673bd8ce96c67ce05de69fe43bc0b87d15a8. Had to revert these two commits, quoting comment 6 of the bug: Thinking again, that entire change is unfortunately wrong, the only right UI manager is in fact gimp_ui_managers_from_name ("<Image>")->data because it's the global popup <Image> UI manager which is independent of a display and it always in the right state for the currently active image, all other UI managers are wrong. app/dialogs/action-search-dialog.c | 124 +++++++++++++++++++++++------------------------------- app/widgets/gimpaction-history.c | 40 ++++-------------- 2 files changed, 62 insertions(+), 102 deletions(-) commit 1517a0952bf56ec7382e3cfea621ca6e4c21d64d Author: Michael Natterer <mitch@gimp.org> Date: Thu Nov 24 21:07:53 2016 +0100 Bug 774890 - "Keyboard shortcuts" dialog does not show all actions Revert "app: do not show the actions from <Dockable> GimpUIManager." This reverts commit b795ae2296ebb4711d7fc6881637506fc422f3ee. app/dialogs/action-search-dialog.c | 24 ++++++------------------ app/widgets/gimpaction-history.c | 2 -- 2 files changed, 6 insertions(+), 20 deletions(-)
Yep sorry. Was going to revert these eventually. I just wanted to implement the alternative in the same time to at least add some actions which would make sense into the search and/or to have shortcuts. How I discovered this was with missing "import palette" action (in relation to the other bug report where you told me of it). I believe that kind of feature is typically something you may want to "discover" through such a search tool. Like what can you do with palettes? Let's type "palette" in the search and see what gets out. And that was only an example, but it looks like there are dozen other actions which are not inside "<Image>" and would deserve be searchable. Maybe these actions' active state is not well updated, but then this can be fixed. So what should we do with these actions?
Since keyboard shortcuts are global, maybe we should simply not try to have actions that are local to a specific dialog?
Can we close this as WONTFIX? It IMO makes sense that this only works for actions that exist in the "global" context.
Well I don't know. Contextual actions also make sense. Also it is not true that the current list is only for the global context actions. There are a lot of actions which are only available when an image is opened, or when some conditions are met (like action to delete a path only when there are paths, etc.). Now that's not a major report and nothing is more broken than before. So let's jump to a "Future" milestone but keep it opened for now.
-- 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/gimp/issues/1009.