|
|
noweld.png (116,016 bytes) |
|
|
Does not work if it results in an invalid operation. Select at least two items. Clipboard 1.jpg (49,844 bytes) |
|
|
Ok thanks that makes great sense, but I wonder rather than not showing the item whether it could be included in the list but in a disabled state? Maybe even list the disabled ones at the bottom? Thus after teaching the user where to find the action it would be a much smaller logical jump for them to make realizing *why* the direct menu item itself was disabled. My use case was just to discover *where* the weld items were living in the menu tree and it didn't help with that in this instance. |
|
|
currently, i'm actively ignoring the actions that are disabled. but i guess that it would not be a big change to show them grayed out. the question is: is it worth to do so? the "action search" is there to make it faster to run a command, without knowing exactly where it is or how is it called. (and without the need to define a specific shortcut.) for this goal, it's probably not useful to add the disabled actions. of course, it can also be used to discover the features that scribus provides or to find out where the actions are in the menus. for these use cases, it could be worth to also list the actions that are disabled. now, it's a tradeoff: a bit more noise in the main case vs. a "small" improvement in the secondary case. technically, the change is probably trivial. this having been said... personally, i'm for keeping the tool as is. except if we can also show the reason why the action is disabled. and, while i would welcome scribus to display the reason why it's turned off, i fear that it's not something that is coming (by itself) soon. (but it would be a nice "first task" for a new junior contributor : - ) let's make a deal: if you're still convinced that this is a must have, just make a patch. you can start from here... https://github.com/scribusproject/scribus/blob/a25cf876a712904b5e01177a704cc00ede1752cf/scribus/actionsearch.cpp#L69 |
|
|
Thanks for great thoughts on the subject. The reason I proposed the change (and initially thought this was a bug) was because I was basing my view of the feature on how macOS surfaces menu actions in its Help > Search that lets you type in anything and it displays whatever you're looking for regardless of what state it's in etc. It's quite invaluable for getting started with a new program before you memorize the locations of things and keybindings etc. I think you're right that there's not too much value in showing disabled items without also showing *why* they are disabled, but the code you linked to is just traversing menus that are already disabled. The reason for them being disabled isn't available unless when the menus are disabled, the reason for this is stored in the menu itself. But storing that sort of state information in the menu items themselves seems the wrong place to keep it, and the reason would have to be cleared when the menu was re-enabled. That might touch a lot of places in the code; but without it I don't know how the feature could work. What are your thoughts on this? My only other idea is if the action search would show things beyond the menu structure itself (such as preferences/settings, or controls inside UIs that are opened by menus). For example "orientation" returns "File > Document Setup > Orientation" and when clicked takes you to the Document setup UI. But this is quite a large change and beyond what might be considered a first task for a new developer on a project. But it does seem like a super useful feature. |
- Anonymous
