The "Search Commands" mechanism should not be limited to those commands already on the menus. There are more commands, and this mechanism in other apps is how they're accessed and used (well, along with keyboard shortcuts). So, basically any command that _may_ be on the menu, should be accessible via Search Commands.
But how would that work for commands that have input and configuration requirements? As is, a command coming from menu UNO action gets a simple launch action--doing much more than that search/locate wise would require way too much effort to provide a launchable action. But still, it would be nice to show .uno: command names in the search. As an alternative to hunting for them in the Tools -> Customize dialog.
Hm, I thought we have ALL commands in main menu because it's our HIG. Isn't it?
(In reply to V Stuart Foote from comment #1) > But how would that work for commands that have input and configuration > requirements? An example might be .uno:FormatBulletsMenu (the menu Format > Lists), which is excluded from HUD and customization. Limiting to what the customization offers sounds correct. And a command not being listed in the menu and therefore not showing up in the HUD is .uno:ContinueNumbering (Add to List) (which is surprising since it's listed under Format > Lists). From the UX POV we loose the educational aspect that commands are shown with their menu position (like "list" => Form / List Box, Format / Lists / No Lists...). Not a bug deal since we could show other commands underneath a separator. Tomaz, any technical blocker?
(In reply to Roman Kuznetsov from comment #2) > Hm, I thought we have ALL commands in main menu If that were the case, the menus would be huge. Go to Tools | Customize and you'll see.
(In reply to Heiko Tietze from comment #3) > An example might be .uno:FormatBulletsMenu (the menu Format > Lists), which > is excluded from HUD and customization. Limiting to what the customization > offers sounds correct. > And a command not being listed in the menu and therefore not showing up in > the HUD is .uno:ContinueNumbering (Add to List) (which is surprising since > it's listed under Format > Lists). > > From the UX POV we loose the educational aspect that commands are shown with > their menu position (like "list" => Form / List Box, Format / Lists / No > Lists...). Not a bug deal since we could show other commands underneath a > separator. > > Tomaz, any technical blocker? context disabled commands are not added to the list
We discussed the topic in the design meeting and agree on the benefit. Since the function by now also educates user where to find the command in the main menu, the change needs to address this. We came up with a couple of ideas: a) change the appearance like italic font, or gray color b) use some textual indicator like brackets [Command] c) some label like "Not in menu: Command" d) positional indicator, ie. use a horizontal ruler and list the non-menu commands below
*** Bug 153001 has been marked as a duplicate of this bug. ***