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

IDE cursor position is wrong if font size is changed in preferences on macOS #194

Closed
processing-bot opened this issue May 7, 2021 · 14 comments
Labels

Comments

@processing-bot
Copy link
Collaborator

Created by: thierry75

Description

in preferences, settings a higher value in "Editor font size" results in having cursor blinking not at the real position, typing will result in inserting code at the wrong place

Expected Behavior

typing code where the cursor blink

Current Behavior

actual cursor is not where the cursor blink

Steps to Reproduce

set Editor font size to 14

Your Environment

  • Processing version: 4.03
  • Operating System and OS version: macOs Big sur and mojave
  • Other information: macbook pro

Possible Causes / Solutions

@processing-bot
Copy link
Collaborator Author

Created by: benfry

I'm not seeing this on my Mojave machine. What font are you using?

@processing-bot
Copy link
Collaborator Author

Created by: sampottinger

Unable to reproduce in 11.4 on the default monospace font. Was this still a problem for you @thierry75?

Screen Shot 2021-07-24 at 6 11 00 PM

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Saw this on someone else's macOS machine, but then wasn't able to reproduce it again. Also not sure if it's something when Processing 4 first runs, and a subsequent launch it's behaving better because preferences.txt has been updated properly.

Also not sure if it's the same as #226, but at the moment I suspect they're different. A lot has changed in the font sizing and prefs code—there was lots of badness in there, but clearly there's a regression.

@processing-bot
Copy link
Collaborator Author

Created by: benfry

For anyone having this issue on macOS, were you using a second display?

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Folks, like the title says, this is only about macOS. There's at least one separate issue for Windows. The problem there is almost completely unrelated, even though the effect sounds similar. If you have Windows trouble, check this issue: #226. If that doesn't describe what you're seeing on Windows, please file a new issue.

Posts about Windows in this issue will be removed to avoid confusion.

@processing-bot
Copy link
Collaborator Author

Created by: benfry

If you're having this problem on Windows, please see #226.

This issue is for macOS—which is a totally unrelated problem. To keep things sane, non-macOS comments to this issue have been removed.

@processing-bot
Copy link
Collaborator Author

Created by: tmatinla

Confirming this happens for me with macOS with 4.0 beta 4. (This is Monterey 12.1 on Intel Mac, 16" late 2019 model)

After setting the font size in preferences, the cursor position is not correct:

kuva

Also not sure if it's something when Processing 4 first runs, and a subsequent launch it's behaving better because preferences.txt has been updated properly.

The problem does not go away if I restart Processing.

For anyone having this issue on macOS, were you using a second display?

I have couple of external displays. The problem actually shows only in the laptop's screen. If I move the window to an external display, the problem goes away (and comes back if I move the window back to laptop's screen).

The problem still happens if I unplug the external displays. Also changing resolution seems not to make any difference.

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Ok, I think it's getting the character widths from the wrong display. Does it work correctly on the "main" display? On macOS that might be the display with the menubar, or dock, or where the Editor window first showed up.

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Also, can you confirm whether it's broken the same way on beta 3 and beta 4? I'm wondering if the fixes for the Windows side have exacerbated this problem a bit.

@processing-bot
Copy link
Collaborator Author

Created by: tmatinla

Does it work correctly on the "main" display?

No, it does not; my "main" display is the laptop's screen where the problem shows.

confirm whether it's broken the same way on beta 3 and beta 4

No, for me, in beta 3 it's actually the other way around: it works on laptop's screen ("main" display), but if I move the window to an external screen then the problem is there (although cursor offset is a little bit different compared to beta 4, but that's probably due to different resolutions).

(I could try run this in debugger if there's something specific to look for.)

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Thanks, that's the information I need for now. Seems we're having a problem with the per-display info about text sizes. A previous change made it work on macOS, but broke the Windows version even for users without a secondary display, so that was more serious. Will look into it.

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Ok, digging into this a bit more, and confirmed that it's not just external displays that cause the issue.

Workarounds for the time being:

  1. Visit Preferences, and select a different font than Source Code Pro. Most others don't have this fractional scaling issue. They may not be as nice, but it seems that Source Code Pro really wants to use fractional metrics.
  2. Also inside Preferences, you'll find that not all font sizes have this issue. On my machine, 12 and 18 were fine, but 14 made things a mess. You'll have different results on different machines.

On a positive note, I'm able to reproduce the issue which makes it drastically easier for me to fix. On the negative side, it's a nasty one. :)

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Fixed with c6d9ba0 for 4.0 beta 5. Phew!

@processing-bot
Copy link
Collaborator Author

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant