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

Improving Cursor Visibility in Hyphenation Check (and other checks using a siimilar window) #631

Closed
okrick opened this issue Dec 31, 2024 · 3 comments · Fixed by #637
Closed
Assignees
Labels
bug Something isn't working

Comments

@okrick
Copy link

okrick commented Dec 31, 2024

When performing a hyphenation check (and other checks using the same style of window), selecting an item in the list highlights the corresponding text in the document. However, the cursor within the highlighted area is difficult to distinguish due to the overlapping colors. This makes it challenging to precisely select and edit specific characters, such as hyphens, within the highlighted text.

To enhance usability, it would be beneficial to implement a different color for the cursor when it is positioned within the highlighted text. This improved color contrast would make the cursor more visible, enabling users to accurately select and edit individual characters within the highlighted region.

@windymilla
Copy link
Collaborator

Thanks @okrick. To help me understand what we can do to improve this situation, I'd like a bit more information, if possible.

  1. Are you referring to the orange highlighting that appears around the corresponding text when you select an item in most of the checking tools, like in this screenshot?
    image
  2. Is the cursor for you remaining the same color as it is elsewhere in the document? It should be black if you are using the light theme (like my screenshot), and white if you are using the dark theme.
  3. Are you using the dark or light theme?

Notes:

  1. Unfortunately, it's not possible to change the insert cursor whenever it enters a highlighted area, so we can't have a different color or appearance when editing in the highlighted area.
  2. However, the default width of the insert cursor is 2 pixels, and that can be increased (in the screenshot below I set it to 5). Note that would be everywhere in the text window, not just in highlighted areas.
    image
  3. Similarly, a borderwidth can be specified for the insert cursor (everywhere in the text window). It makes a kind of raised cursor - here's a screenshot of width=6, borderwidth=3
    image

If either 2 or 3 would be generally useful features to aid cursor visibility, not specific to within highlighted areas, we could possibly add something to the preferences.

@windymilla windymilla added the future feature New feature or request, but not core label Jan 1, 2025
@okrick
Copy link
Author

okrick commented Jan 1, 2025

I'm using the dark theme for GG2 to help me remember which one I'm using although I'm unsure why since they don't look much alike.

However, the issue is not the cursor itself. The cursor seems to disappear in both light and dark mode when I shift-move the cursor over one or more characters in the orange WF highlighted area. The highlighting provided to an area by a shift-move of the cursor is normally blue in either dark or light mode. The orange WF highlighting overrides the blue selection.

@windymilla
Copy link
Collaborator

windymilla commented Jan 1, 2025

Ah, that makes sense. I shall consult with my esteemed colleagues ;) and we'll formulate a plan to improve that situation.

Edited to add: the fix for this is already in the pipeline.

@tangledhelix tangledhelix added bug Something isn't working and removed future feature New feature or request, but not core labels Jan 1, 2025
@tangledhelix tangledhelix self-assigned this Jan 1, 2025
tangledhelix added a commit to tangledhelix/guiguts-py that referenced this issue Jan 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants