UI: Dim Text Editor Caret and Selections When Inactive
AbandonedPublic
Actions

Authored by Harley Acheson (harley) on Jun 9 2019, 11:39 PM.

Details

Reviewers

Brecht Van Lommel (brecht)
William Reynish (billreynish)
Campbell Barton (campbellbarton)

Summary

The way that editors are only active while the mouse is inside them can be problematic for the text editor. For that editor the mouse can get in the way so you might move it right out of the space and suddenly you don't know why your keys no longer work.

This patch makes the active caret position, selection areas, and line highlight all dim when the editor loses focus when you move the mouse out of it.

The top of the following image shows what it looks like when the mouse is positioned inside the Text editor area. To the right is what it looks like when you move your mouse outside of the area:

Diff Detail

Repository: rB Blender

Event Timeline

Harley Acheson (harley) created this revision.Jun 9 2019, 11:39 PM

riidom (riidom) added a subscriber: riidom (riidom).Jun 10 2019, 12:46 AM

riidom (riidom) awarded a token.Jun 10 2019, 12:48 AM

This helps a lot with communicating which text area has the focus. Nice.

This revision is now accepted and ready to land.Jun 21 2019, 11:34 PM

Has this been committed yet? Maybe in addition, it could be considered to give the Text Editor a typing focus, like the text entry boxes?

In this gif I type continuously while moving the mouse. Notice the difference between the text editor and the text entry box:

In the Text Editor the typing stop in the Text Editor when the cursor is "outside" and the typing is inserted in the Python Console when the mouse is there. Where as typing in the Text Box is continuous, until there is a mouse click outside of the text box area.

Has this been committed yet?

No, I forgot about it to be honest. Text editor has had some work so will make sure this applies then
poke someone.

Notice the difference between the text editor and the text entry box

The entry boxes have to retain focus once it gets it, but we don't (currently) have a notion of sticky editors. So it would be odd to move to some other editor, press some hotkeys and nothing happened. So would be missing is a way to get out of that.

The thought of making an entire editor "sticky" is always something to consider, and would come in handy if we really want centralized toolbars. But it would require a common way to make an editor so, remove it from that mode, and some way of indicating that the editor has that status - like with a change to the border around it. But that would be a big change for Blender as we've done so well without it - only the Text Editor (and aborted common toolbars) being the outliers.

Rather not have this behavior, it makes the interface flash in a neurotic way while moving the mouse.

There is already subtle change to the header color to show the active area, if these are too subtle, I think we should solve this in a general way which applies to all areas instead of changing the color of the area content. Which isn't all that a reliable way to show focus, in the case you don't have a selection.

These kinds of design decisions can always be rationalized, however consider that many IDE's/editors support multiple windows and don't change the color of selection as you move the cursor over the windows.

If we accept this as a problem that needs solving by changing area content, we could apply this to other areas in Blender.

Are there reasons not to apply this to 3D text in the viewport? why not 3D view object selection?
Is text editing a special case where this makes sense?

Campbell Barton (campbellbarton) requested changes to this revision.Aug 19 2019, 1:08 PM

This revision now requires changes to proceed.Aug 19 2019, 1:08 PM

Campbell Barton (campbellbarton) mentioned this in T68830: Highlighting active area (design task).Aug 19 2019, 4:42 PM

This is a case where patches are more design topics, if it's a problem that the active area isn't obvious, I'd like to see this handled as a design task instead of a one-off change in the text editor.

Posted T68830: Highlighting active area (design task), we should have this resolved first before making code changes.

@Campbell Barton (campbellbarton) : If it's a problem that the active area isn't obvious, I'd like to see this handled as a design task instead of a one-off change in the text editor.

Yes, thanks for making that design task. I have done many experiments with active-area highlighting, but have yet to find anything that alerted enough when needed yet wasn't annoying in the general case of just moving your mouse around. But maybe someone else can come with something that works.

For this particular problem though, the Text Editor is a special case in that the primary activity is so disconnected from mouse usage.

But really not seeing how this change added "flash in a neurotic way" since the primary change you would generally see is just a slight dimming of the red text caret. You would only see a larger change if you actively had a selection of text highlighted while moving your mouse from the area.

In D5047#126284, @Harley Acheson (harley) wrote:

@Campbell Barton (campbellbarton) : If it's a problem that the active area isn't obvious, I'd like to see this handled as a design task instead of a one-off change in the text editor.

But really not seeing how this change added "flash in a neurotic way" since the primary change you would generally see is just a slight dimming of the red text caret. You would only see a larger change if you actively had a selection of text highlighted while moving your mouse from the area.

My concern is that if it's subtle, it's not solving the problem, if it's not subtle, it solves it while being distracting/noisy.

Having a block of text selected isn't the default state of a text editor, only changing the caret feels so subtle as to be unhelpful.

Programmatically blending colors often more trouble then it's worth, with some themes the colors become impossible to see, or we need to add theme settings for active/inactive cursor+selection.

@Campbell Barton (campbellbarton) - My concern is that if it's subtle, it's not solving the problem, if it's not subtle, it solves it while being distracting/noisy.

Yes, no worries. Have rambled on in that task you set up. LOL

I'm fine with parking this issue for now. It’s not completely clear how to solve this issue in a general when we use sloppy focus. Either it will be too flashy and distracting, or it will be too subtle to notice.

Closing for reasons stated above.