Page MenuHome

UI: Do not block navigation events while a button is in edit state
Needs ReviewPublic

Authored by Vincent Blankfield (vvv) on Dec 6 2020, 12:37 AM.

Details

Reviewers
Hans Goudey (HooglyBoogly)
Group Reviewers
User Interface
Summary

Allow WHEELDOWNMOUSE, WHEELUPMOUSE and MIDDLEMOUSE to be passed through the textedit button event handler. This will allow navigating the search results, when the text input focus is in the search field.

Problem

Editable buttons like UI_BTYPE_TEXT, UI_BTYPE_NUM, UI_BTYPE_NUM_SLIDER and UI_BTYPE_TAB block too many events when in BUTTON_STATE_TEXT_EDITING state. From the user experience perspective, this blocks the input that has nothing to do with the text editing, and in most other software don't require a text input focus to be in the receiving widget or window. Example of such actions is scrolling. Most notably, it is impossible to scroll the search results while the search box is in the edit state (see video examples).

Before:After:

Diff Detail

Repository
rB Blender

Event Timeline

Vincent Blankfield (vvv) requested review of this revision.Dec 6 2020, 12:37 AM
Vincent Blankfield (vvv) created this revision.
Hans Goudey (HooglyBoogly) requested changes to this revision.Dec 12 2020, 12:17 AM

Thanks for looking into this! I was planning to but never got around to it. Indeed it's pretty annoying to have all shortcuts locked while searching.

In order to do code review properly though, we'll need to split out the functional changes that actually fix the issue from the cleanup and renaming also included in this patch.
This is very important for reviewing changes, by making the job of a reviewer much easier, and by clearly separating functional and non-functional commits.

With that in mind, could you split off all of the cleanup changes to a separate patch? A simple cleanup patch should generally be accepted pretty quickly.

This revision now requires changes to proceed.Dec 12 2020, 12:17 AM
Vincent Blankfield (vvv) edited the summary of this revision. (Show Details)

Removed unnecessary edits.

This seems to work well for me. It does expose a little bit of weirdness, for example, ctrl-F selects all of the text when the search button is already focused. However, that's a lot less weirdness than the way it is now.

It does seem natural for ui_do_but_textedit to return its return value anyway.

I would like either @Julian Eisel (Severin) or @Campbell Barton (campbellbarton) to look at this though, they would have a much better idea of whether there is a good reason not to do this.

Thanks for checking this out.

In my opinion, selecting all the text in the search box, on starting a new search by Ctrl+F is a desirable behavior. It's much quicker than having to delete the previous text first, when trying a new search term. Though I didn't plan for this.

Vincent Blankfield (vvv) planned changes to this revision.Dec 17 2020, 3:51 PM

This revision currently has a flaw.

Steps to reproduce:

  1. Open a couple of editors that have a Ctrl+F accessible search (e.g. File Browser, Properties, Asset Browser).
  2. Press Ctrl+F in each of those editors.

Result: Each search box will go into edit state.
Expected: Either exit edit state on the previous button before entering in the next one, or don't allow the next button to go into edit state.

As a consequence, when multiple buttons are in the edit state, it will require multiple events to exit it. For example when there are 3 search fields in edit state, it will require 4 clicks to activate another button.

In general it's unclear what the effects are of making this non-blocking. You can delete objects, open a file browser, insert keyframes, split the editor, etc.

It may be that those things work fine, but this needs some stress testing to find out what happens in such corner cases.

I was skeptical too and checked out the patch a bit ago - it seemed reliable, but I only really played with it for a minute. Indeed what troubles me is that it's hard to estimate consequences and possible corner cases. It's removing an isolation that was there since a very long time, code was built around it.
Might also be a good idea to do some testing with the PreferencesExperimentalLegacy Undo enabled, since the new undo does as little work as possible and thus tends to disguise some issues (while still having its own ones).

That said, if this can be made to work well, it's a great and welcome improvement.

@Brecht Van Lommel (brecht) Agreed. And my current plan is to pass through only the events we are interested to pass through (WHEELDOWNMOUSE, WHEELUPMOUSE, MIDDLEMOUSE, maybe something else like zoom, etc.). For that I intend to leave everything as is in this patch, but modify ui_do_but_textedit so it blocks everything except those events. Currently it passes through every event it doesn't handle. Though I need a bit more time to play with this to check if I'm not missing something.

Only pass through the events we really need (WHEELDOWNMOUSE, WHEELUPMOUSE, MIDDLEMOUSE). This avoids another button being put into edit state by a hotkey operator, while a previous button is in edit state. Also it greatly reduces the possible impact of this change making it safer. Overall, before this patch all the events were blocked, after - only the mentioned 3 are passed on.

I couldn't come up with more events that can be useful when a button is in edit state, but the list can be extended later.

Vincent Blankfield (vvv) retitled this revision from UI: Do not block all user input events while a button is being edited to UI: Do not block navigation events while a button is in edit state.
Vincent Blankfield (vvv) edited the summary of this revision. (Show Details)

Fix an issue with searchboxes: Events, for which ui_searchbox_event returned true, weren't blocked in ui_do_but_textedit.

Before:After: