Improve keyboard usage for spacebar search menu
Open, LowPublic


System Information

Blender Version
Broken: example: 2.78
Worked: >new feature request<

Short description of error
when spacebar search menu popups and user start writing the required command, only down-arrow keyboard shortcut are allowed to select the required command, starting from first item on top.
It will be very useful and faster if also up-arrow can be usable to select the last item in the list (so starting from bottom).
See image as reference: green arrow show the required feature, red one is the only one actually working.

Exact steps for others to reproduce the error
not an error, only UI usage improvement :)



This does not seem complicated, and would really be useful!
@Julian Eisel (Severin), could you take a look?

Campbell Barton (campbellbarton) changed Type from Bug to Design.

Seems reasonable, moved to quick hacks since this is a nice one for new developers.

I always propose easy and fast hacks, but unfortunately I'm not a coder, so I can't do it myself (and I don't want broke something) ;)

Hi, first-time contributor here! I've created a patch with this new feature, plus a short screencast attached.

One issue evident in the screencast is how long it takes to wrap from the top of the searchbox to the bottom for long item lists. This happens because I'm calling ui_searchbox_update in a loop, but I don't know any other way to access the end of the item list/the size of the item list. Furthermore, where is the value of items.more assigned?

Any feedback is greatly appreciated!

Hi @Karina Antonio (karinafantonio),

I liked your code but one thing worries me...
It's this part:

while (data->items.more) {
	data->active = data->items.totitem - 1;
	ui_searchbox_update(C, ar, but, false);

We can have about 2000 items in a list
ui_searchbox_update in a loop can be quite inefficient.
So, if it were not for this detail, I think the patch would already be good to commit.

Ahh, I see. Here's the updated patch with that part removed.

Using (and making!) this patch feels really nice!

blend-it (blend-it) added a comment.EditedApr 3 2017, 10:38 AM

Thanks for working on this feature :)
I nothing understand about the code, but if there are a performance issue, I can suggest you can trigger your routine only when:

  • letters in searchbox are more than 3,4 or 5 (the consequent list is shorter so faster to process,) and/or
  • the list itself is shorter than 6-10 items (is less useful to scroll from bottom if the last item is not visible to the user).

Hi, no problem, it was fun to do and a nice feature to have! ^^

The patch adds scrolling from bottom to top for all list sizes, and scrolling from top to bottom only when the entire list is visible (so when the list is <= 10 items). No performance issues at all for these cases, there are only issues for the case of wrapping from top to bottom with large lists with many not-visible items (so my latest patch disabled wrapping in this case).

@blend-it (blend-it) changing behavior based on number of letters typed will seem buggy from user perspective.

I don't see why wrapping the list would have to be a slow operation.

@Campbell Barton (campbellbarton) About the number of letters typed, I understand your point, but with less of 3/4 letters the list is so long and user can't see the bottom, so I think nobody try to scroll from an "invisible" bottom.
Anyway, I can't compile and try to check performance, so if you don't find this kind of issues, no problem!
Thanks to all and I hope to find the feature in 2.79 ;)

the patch was not included in 2.79.... it's possible for 2.79a? :)

where can i find the definition of data->active, items.totitem, items.more and items.offset