Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve cursor in text editor #8473

Open
inhalt120g opened this issue Nov 19, 2023 · 11 comments
Open

Improve cursor in text editor #8473

inhalt120g opened this issue Nov 19, 2023 · 11 comments

Comments

@inhalt120g
Copy link

inhalt120g commented Nov 19, 2023

Describe the project you are working on

A classic arcade game.

Describe the problem or limitation you are having in your project

The cursor is just too small, it's basically one pixel wide. It's really hard to find on big monitors especially when zoomed out. I know there's also the "caret" options but that one is a bit weak too (again, one pixel width???).

I even set it to blink a bit faster and finding cursor is still a pixel-hunting expedition half of the time.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The cursor should have a few options for thickness.

Additionally, for extra visibility, an option to combine a full caret (as opposed to an outline, like it is now) + single line cursor would be most welcome!!!

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Two pixels thickness:
image
Three pixels thickness:
image

Two pixels + highlight! No more chasing one - pixel wide cursor! (the highlight uses the same color as cursor at 25 % opaqueness)
image

If this enhancement will not be used often, can it be worked around with a few lines of script?

???

Is there a reason why this should be core and not an add-on in the asset library?

I'm not sure this can be an add on?

@Calinou
Copy link
Member

Calinou commented Nov 19, 2023

godotengine/godot#58700 addresses the caret width part of this proposal.

As for the second part of the proposal, I haven't seen this in any other editor. If we provide such a setting, I don't know how often it would be used. Are there add-ons to replicate this in other editors? I'd like to try this for myself in VS Code and see if it's a worthwhile change.

@inhalt120g
Copy link
Author

inhalt120g commented Nov 19, 2023

Yes, 58700 looks like it, I was searching for "cursor" and similar but haven't seen it.

About the second part and how often would it be used:
To my knowledge, sadly there aren't such options elsewhere. I sure wish there were, as a person whose eyesight is not among the best. I expect it will be used in minority of cases, like as often as there are setups where text is a bit zoomed out, or where people's eyesight is a bit on the weak side or who are more skilled at things other than touch typing or who just like things to be nice and visible.

@Mickeon
Copy link

Mickeon commented Nov 20, 2023

Showing the full caret at all times sounds potentially confusing. I get the reasoning, but since the text editor used by Godot itself derives from the TextEdit class, this functionality may be exposed as a property, too. How many would make use of it?

@inhalt120g
Copy link
Author

inhalt120g commented Nov 20, 2023

"Showing the full caret at all times sounds potentially confusing"
I agree, that's why I didn't propose showing full caret at all times (the proposal is about "line" type cursor, with a potential "subtle highlight" for extra visibility, but the caret itself is still visually at least one line). For the same reason I also didn't propose the chunky "DOS terminal" type cursor, which has a nice visibility but it's slightly illogical that it's adding characters behind itself and not where it currently is.

@inhalt120g
Copy link
Author

inhalt120g commented Nov 20, 2023

There's a setting that looks like it's meant to do what the second part of the proposal is suggesting (caret background color):
image
…but it's currently unused so I can't check it:
image

@Calinou
Copy link
Member

Calinou commented Nov 20, 2023

@Paulb23 @bruvzg Do you know what caret_background_color was supposed to look like in the script editor?

@bruvzg
Copy link
Member

bruvzg commented Nov 20, 2023

Do you know what caret_background_color was supposed to look like in the script editor?

No idea, it seems to be unused.

Two pixels + full caret! No more chasing one - pixel wide cursor! (the carret uses the same color as cursor at 25 % opaqueness)

There's already support for block caret, so adding support for something like this should not be hard. But note that caret in the bidirectional text can have additional forms (split caret + direction markers, and ligature caret) which should be accounted for as well.

caret_forms

@inhalt120g
Copy link
Author

The way I imagined the "highlight" (I wrongly called it "full caret" in the original proposal) to behave is exactly the same like what the "block" type cursor does in the current version (so I assume all the logic for all languages is already implemented).

Including, for example, how the block-type cursor actually covers the tab when the cursor is on the left from the place where the tab is (although in the current implementation it's a bit confusing because it's not clear at a glance where the actual cursor is). The "highlight" part of the cursor could inherit all the behaviors from the current block-type, only drawn solid as opposed to current 1-pixel outline-only (same for the "main" part of the cursor, it should continue behaving the same when drawn a bit thicker).

I don't know how the block-type cursor behaves in bidirectional text but in all the contexts I tried it with (GDScript, Chinese, Japanese) it worked well.

@Paulb23
Copy link
Member

Paulb23 commented Dec 7, 2023

caret_background_color should be the colour of the text behind the caret when block caret is enabled, but currently there's a bug where it's not actually used anywhere.

@inhalt120g
Copy link
Author

If this is a bug, should I file it under issues?

@Calinou
Copy link
Member

Calinou commented Dec 18, 2023

If this is a bug, should I file it under issues?

Yes, I suggest opening an issue for what Paulb23 pointed out 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants