Adds tooltips to searchable menus
Details
Diff Detail
Event Timeline
Thanks Blendify for setting the repository and projects. This is my first time submitting C code, so I wasn't sure about repository or projects.
Note that we have ~1600 operators and some of the descriptions are quiet long, (maybe even longer in future D1493)
So think we could either...
- Make this array pointers to const char * (pointers to the strings instead of allocating duplicates).
- Pass in a callback to search which can fill in a tool-tip string, which is only called when the tool-tip is displayed.
The first option is by far the most simple to do, but means all strings need to be static (pointers must remain valid).
Campbell Barton, I'm not quite sure what you're referring to; do you mean line 3300 of interface_templates.c?
@Ryan Inch (Imaginer),
Checked line 3300, but not sure how it would relate.
The main point is that you could potentially copy a lot of strings (every operator description), on the off-chance - you might want to show a tool-tip for one.
With the names its they're all short and mostly on display anyway...
but with the tool-tip - it could be looked up as needed.
So just to make sure, you're suggesting that I fix UI_but_string_info_get to correctly get the info for the search menu instead of just collecting it all and then assigning it to but->tip when needed the way I'm currently doing it?
Close, though I don't think any modifications there are needed. Since buttons have a callback for tips.
uiBut.tip_func.
Its possible to set a general callback that can do the tip lookup.
Am not too confident with how this works, it changes code in quite a few places and seems rather fragile/error-prone.
However this is quite hard to do in a nice way too, (I attempted to improve on this patch but I think it needs larger changes to how the searchbox works).
So not sure what to advise here, it would be nice to fix - but but think this requires bigger changes.
| source/blender/editors/interface/interface_regions.c | ||
|---|---|---|
| 960–1005 | This function bypasses the design of the search callbacks - and hardcodes logic for all search callbacks into one places. Its not really fitting the design of having a generic search callback popup. | |
| 1004 | This is leaking memory, (run blender with --debug argument). | |
| 1036–1041 | This changes the logic more than is needed IMHO. Why not simply return if the active item is changed or not? return (data->active != active_prev); ... where active_prev is set at the beginning of the function. | |
I don't really want to rewrite the whole search menu and I'm not really familiar enough with blenders ui code to do that;
however, since this is the only thing (that I am aware of) that is really missing a whole rewrite doesn't seem warranted.
The only part of my code, that I can think of, that might be error prone is the ui_searchbox_tooltip_func. It assumes
that you are either dealing with a search menu made up of operators or enums; if the search menu is made up of
other things it might fail, but I think I have accounted for everything.
| source/blender/editors/interface/interface_regions.c | ||
|---|---|---|
| 960–1005 | This function is designed to return the tooltip string for the selected item in the search menu and shouldn't have any effect on search callbacks themselves. | |
| 1004 | I ran blender with the --debug argument and as far as I can tell it's not leaking memory on my system. On a side note I have seen similar usages of this in other areas of blender's code. | |
| 1036–1041 | Because I also need to trigger a tooltip when there is only one item in the list; hence, the active item never changes and so I need the extra logic specifying the first item should trigger a tooltip if there is only one item. I can simplify it a bit by getting rid of retval and simply returning 1 if a tooltip is needed and 0 if it isn't. | |
The search menu is currently being reworked, see T74157 and rBc46dcdf8871e. Closing the patch for now, as that seems more like the way forward.
@Julian Eisel (Severin) Thanks. Blender's internal code may have changed by now anyway.
For the record, this patch was primarily focused on the python search menus for addons and not the operator search menu (though I'm pretty sure it got tooltips from this as well).