Page MenuHome

UI: Widget Text Cursor Color
AbandonedPublic

Authored by Harley Acheson (harley) on Sat, Nov 23, 9:15 PM.

Details

Summary

Users are able to change the color of the text cursor (insertion caret) in the Text Editor and Python Console. But the color of that cursor everywhere else, like when changing property values or text in Properties or Preferences, is hard-coded as {0.2, 0.6, 0.9}

This patch add a theme setting to change this color. This could be important for different themes, or for users who have some color vision deficiency:

Further, this patch slightly alters the size and placement of the cursor. The current code does not scale the width of the text cursor with changes to scale and dpi, so it is more difficult to see for users with high-dpi displays like Retina. It also places the cursor slightly to the right in the space between characters. And it also varies its height in a way that does not follow scale correctly.

The following illustrates these changes, with current behavior on the left, after patch on the right. 1X, 2X, and 3X scale zoomed in to show it better. It shows the change in width with dpi and user scale changes. The better horizontal centering. And you should see it fixes the vertical size issue on the left where the caret and selection underflows, then perfectly fits, then overflows the input area bounds.

Diff Detail

Repository
rB Blender

Event Timeline

I'm not sure why it didn't get review yet, but there was already a patch for this that came out of this discussion in devtalk: https://devtalk.blender.org/t/theme-development-paper-cuts/

https://developer.blender.org/D6024

@Alessio Monti di Sopra (a.monti) - I'm not sure why it didn't get review yet, but there was already a patch... https://developer.blender.org/D6024

Yes, didn't notice that.

Looks like his theme stuff is identical to this, so we should just go with his and then I can (maybe) later add my cursor-drawing changes afterward.

Seems ok to me - st least we should fix the width respecting DPI properly.

@Pablo Vazquez (pablovazquez) are you ok with adding this theme entry?

This revision is now accepted and ready to land.Sun, Nov 24, 3:56 PM

FYI, if we get code approval on either I can commit Paul’s version (change author) and then commit my (small) scale changes afterward.

Campbell Barton (campbellbarton) requested changes to this revision.Mon, Nov 25, 2:26 AM

Generally LGTM, minor change requested inline.


Committed rBb92ac3e2cbd7: UI: scale widget cursor by pixel size separately since it's unrelated to cursor theme.

release/datafiles/userdef/userdef_default_theme.c
241

There are multiple kinds of text cursors (text object, text editor, console... etc).

This could be called widget_text_cursor, DNA/RNA, define etc.

This revision now requires changes to proceed.Mon, Nov 25, 2:26 AM

@Campbell Barton (campbellbarton) - Committed rBb92ac3e2cbd7: UI: scale widget cursor by pixel size separately since it's unrelated to cursor theme.

Thanks! Sorry to muddy things up. I just hate bugging you with multiple little things. But then just made more work for you anyway. LOL. Will try to keep things more atomic.

Generally LGTM, minor change requested inline.

Yes good points. Will make these changes and then commit as D6024, setting Paul (Thirio) as author as his patch was earlier. Then abandon this revision. Unless I am being brain-dead. But will assume this is all okay unless you say otherwise.

patch was submitted over a year ago by me..
nobody seemed willing to theme this.. we already have enough settings.. very frustrating to see people jump aboard with THIS patch..

https://developer.blender.org/D3979

Cursor size and placement changes were committed by Campbell separately: https://developer.blender.org/rBb92ac3e2cbd7c64838e2cb760dd33c011f8d429d

The other changes (almost exactly) match an earlier patch, so changes made here as per reviewed by @Campbell Barton (campbellbarton) and then committed as https://developer.blender.org/D6024 with author set to him

@Roel Koster (kostex) it is quite unfortunate that this happened this way. If it was up to me, we'd still have a much higher threshold for considering a new theme value as worth it. During 2.8 work (at a time when I wasn't involved much) people just started adding theme colors again, without putting efforts into thinking about alternative solutions (e.g. auto-contrasting or smarter re-using of existing colors). I think we now have way more than 800 theme options exposed to the user, which is quite embarrassing and points at a big design flaw. See T45352.
I have plans and ideas to address this, but it's a long-term task.

So I'm afraid the inconsistent treatment here was caused by the dynamic, sometimes not too organized process we had during 2.8. Again, if it were up to me, we wouldn't allow any new theme colors without good reasoning and without having investigated alternatives first. The latter was not done here, or in any similar recent occasions.

For me I see these as separate issues. Some users have a real and legitimate need for this, while we also have a faulty design. Both of these things can be addressed, but there is no need to make users wait for us to fix our design.

Could the text input caret be highlighted without any setting at all? Possibly if we were to choose either white or black depending on the background color if we also had the ability to make it blink like other applications. In other applications the caret is a shared resource and is handled and drawn by the OS. In our case we might have several at once and it would be hard to allow only one at a time since we don't handle enter/leave very well. But a single, shared, blinking caret would be nice to have.

We have three color settings for text input caret. Do we need them all? No, we could have one, but only if we made restrictions in other theme settings. Right now we allow the backgrounds of buttons to be different from the background of text editor, which can be different from the background of the python console, all having text input. In an ideal world a theme would not be so granular and a "dark" theme would set the same dark color to all similar backgrounds, rather than allow each to be different.

So I fully agree that we have FAR too many theme settings. We give so many choices that now making those choices is getting very difficult. The process of making a theme is onerous because of the multitude of settings.

In this case it is a singular thing (text input cursor) that needs to have three settings because of all the other options we already allow. But consider the color you get when highlighting a selection. In the default theme that might seem like just a blue used all over, but it is a multitude of settings all over the theme. If you are highlighting text within a text input that is set with Text / Item, while Text / Selected is the color for the entire input when selected, but just for that type. Select part of a number and that is Number Field / Item and it has a separate Number Field / Selected. LOL

So something like https://developer.blender.org/T45352 would be awesome, although might need a good think and design. But in the mean time we can't really ignore users that have legitimate difficulty with a such an important issue as editing input, just because our design is faulty.