Page MenuHome

Show categories in search-box

Authored by Campbell Barton (campbellbarton) on Feb 3 2016, 11:36 AM.



This diff shows the categories for each operator in the operator search popup.

This helps by giving some context to the operators which are often named assuming they will be access from a menu where the context is already quite obvious.

Example of a similar tool search popup for the atom editor.

One problem with this patch is the categories for operators is currently an 'internal' field that users never see, so its not always so user-friendly
(wm instead of WindowManager, ED instead of Editor for example).

We could always have a lookup table stored that shows a more friendly name, but this would ideally need to be extended so addons could include their own prefix, which gets a bit messy.

Diff Detail

rB Blender

Event Timeline

Bastien Montagne (mont29) accepted this revision.

Big +1 for me, this is much much better than current op search box - and I think that minor glitches like Wm or Ed are not a reason to stop it. ;)

We can also rename those categories to better names, noisy change for sure but not that hard I think (except maybe some issues with addons?).

Also, when name is only two or three letters, you could keep it all capitalized (UI, ED, WM, UV…)?

This revision is now accepted and ready to land.Feb 3 2016, 1:26 PM

+1 This looks good.

Capitalizing small names sounds good too. I don't think addons will be much of a problem. Most of them use the addon name as the op category. There could be a small tip in the "best practices" in the API docs to push devs into writing descriptive categories.

Users can infer that names on the left side are categories (because they repeat), so it's not necessary to repeat the ":".

Also, it could be useful to differentiate the hotkeys with a different color. Like the engine name in the "render engine" tooltip for instance.

Julian Eisel (Severin) edited edge metadata.EditedFeb 11 2016, 1:41 AM
Julian Eisel (Severin) requested changes to this revision.

Big +1 for the feature itself.

I guess code is not finished yet? Has some weird looking things in it, like unused uiSearchboxData variable, ELEM check for single element, etc ;) A major issue is that it's currently just always calling ui_searchbox_region_draw_cb__operator instead of ui_searchbox_region_draw_cb, causing crashes for all non-OP search menus. Only solution I see would be adding something like UI_BLOCK_SEARCH_MENU_OT flag or UI_BTYPE_SEARCH_MENU_OT button type :/
Would also pack code for getting category from OP name into own util function, guess you'd do that anyway though.

EDIT: Maybe adding UI_BTYPE_SEARCH_MENU_OT wouldn't be that bad. If we at some point (hopefully soon) change to an inheritance based uiBut struct such variations can be turned into flags for a specific button type, so we shouldn't worry that much about it.

This revision now requires changes to proceed.Feb 11 2016, 1:41 AM

Another minor annoyance is that for abbreviations, only the first letter is written in capitals... (Wm, Ui, Ed) Not a big issue, but keeps bugging me :S If we add a util function for getting category out of name, maybe an ugly hardcoded string comparison would be okay to avoid that? Or maybe a if (strlen(str) < 3) check or similar.

  • Resolve mistake where all search buttons were assumed to be for operators
  • Don't change the size of _all_ search popups, instead just make operator searches larger.

@Julian Eisel (Severin), thanks for checking - and excuse the errors, would normally take more care, this was an experimental change I had stashed from months ago and decided to upload it for initial review (to see if we even want to have this functionality).

Went over the patch in more detail fixing 2 issues, and think its stable/ready for master now.

Wm Ui and Ed also bug me :S. tsk!


This should be committed separate, I was getting an assert here IIRC.

I've not tested this yet but also major +1 from me for usability improvement.

Should be fine to commit now? :)