Command palette menu

[makoConstruct]

A sublime-style command search bar is easily the best way to access any feature that wouldn't have a dedicated on-screen button, or that would be used infrequently enough that the user couldn't be expected to remember its keybinding. You are going to end up with a lot of those sorts of features.

Command searchers are also great for confirming or disconfirming the presence of a feature, discovering related features, or even just as an alternative to keybindings, they're often barely slower to use than keybindings, and they're always faster than clicking through menus.

If you are already maintaining hierarchical menus, a command bar requires no additional upkeep, it is just a search over the names and descriptions you're already maintaining.

Hierarchical menus will probably always have to be kept around for mouse-only users, but for anyone who uses a keyboard, well, for me at least, menus completely fall out of use, they're never preferable.

Command searches might have a bit of a discoverability problem, they're not visible when the user isn't interacting with them. I guess we could solve that by detecting when a user has a keyboard, uses, it, and is fumbling a bit in using the menus, then telling them "press Ctrl+P and type the name of the feature you're looking for" once or twice.

---

Implementation thoughts

This likely goes hand-in-hand with #741 since it requires a refactor to more properly define what an "action" is from a global list, like it is in Blender; and such a refactor will likely be done in concert with that issue too, as well as #1544.

The de facto standard for keybinding for these seems to be Ctrl+P. Ctrl+R is also used for quick searchers, in subline, and might be easier to remember (R is for Run).

The best algorithm for these seems not to be the obvious search ranking algorithms. It should prefer to match initialisms, then whole words, and only after that should it resort to ranking results by hamming distance. This tends to let users narrow in on the feature they're looking for with as few keystrokes as possible, often to the point of making keybindings unnecessary. A while back I wrote up an algorithm that works this way, that I was quite happy with: https://github.com/makoConstruct/CleverMatcher/blob/master/CleverMatcher.coffee

That algorithm is just a linear scan over the whole set, I'm not sure that it will feel responsive enough once there are multiple hundreds of features, although it's conceivable that the main command search should be limited to only the most used 95% of features to avoid clogging search results with strange things.

But I don't think it should stop at 95%, maybe in another section, or under another keybinding, or perhaps after pressing Ctrl+P a second time? Or tab? a command search could make every preference and config instantly accessible. I've never seen any application go that far, I think I can see why they might not have done so, but I think I can see solutions. They might not have thought of showing those extra results in a separate section, they might not have thought of giving the program enough information about the types and allowed values of their preferences/conf variables so that the program could create a reasonable UI for working them. In sublime, the standard workflow for editing a config variable is to open the config text and ctrl+f it. This seems reasonable, but I think it would actually be substantially slower than having a command search that knows about preference/config variables.

Even without covering config variables, of course, this would be a very useful feature.

---

(I should also probably introduce myself. I'm a rust programmer and a frequent vector graphics user, I might actually want to implement most of this if the project is receptive to it.)