View Issue Details

IDProjectCategoryView StatusLast Update
0017263ScribusUser Interfacepublic2024-09-13 13:39
ReporterBN_Dev Assigned To 
PrioritylowSeverityminorReproducibilityalways
Status newResolutionopen 
Platformx86_64OSLinux/macOSOS VersionAll
Product Version1.7.0.svn 
Summary0017263: Action Search missing items
DescriptionI was just trying out the weld feature and wanted to find where it was located, so I went to Help > Action Search to find it. Entered text "weld" and the feature was not surfaced. Found the feature exists in Item > Welding menu. Initially I thought it was just the weld feature missing but I experimented a bit and also noticed other action items were not surfacing, such as "group" brings up no results. Other search words such as "lock" and "layer" do return results from the Item menu.
Steps To Reproduce1. Go to menu Help > Action Search
2. Enter text "weld" in the search box
3. Observe no results found

Expected result would contain "Weld Items (Item > Welding)"
TagsNo tags attached.
PatchNo

Activities

BN_Dev

2024-09-07 14:40

reporter  

noweld.png (116,016 bytes)   
noweld.png (116,016 bytes)   

PeterBenedek

2024-09-08 14:11

developer   ~0051311

Last edited: 2024-09-08 14:13

Does not work if it results in an invalid operation. Select at least two items.
Clipboard 1.jpg (49,844 bytes)   
Clipboard 1.jpg (49,844 bytes)   

BN_Dev

2024-09-09 01:33

reporter   ~0051312

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.

ale

2024-09-09 14:09

manager   ~0051313

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

BN_Dev

2024-09-13 13:39

reporter   ~0051335

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.

Issue History

Date Modified Username Field Change
2024-09-07 14:40 BN_Dev New Issue
2024-09-07 14:40 BN_Dev File Added: noweld.png
2024-09-08 14:11 PeterBenedek Note Added: 0051311
2024-09-08 14:11 PeterBenedek File Added: Clipboard 1.jpg
2024-09-08 14:13 PeterBenedek Note Edited: 0051311
2024-09-09 01:33 BN_Dev Note Added: 0051312
2024-09-09 14:09 ale Note Added: 0051313
2024-09-13 13:39 BN_Dev Note Added: 0051335