sampottinger / processing

Source code for the Processing Core and Development Environment (PDE)
http://processing.org
Other
10 stars 1 forks source link

Cursor position is off on mac #103

Closed clankill3r closed 5 years ago

clankill3r commented 5 years ago

OSX 10.12.6

2019-08-28 11 25 33

sampottinger commented 5 years ago

so strange... I’ve been living on my processing branch in Mac for a few months and haven’t seen that yet. I’ll investigate more and report back.

sampottinger commented 5 years ago

Hey @clankill3r! Thanks for submitting this. :) Unfortunately, I can't seem to reproduce this in mainline or in my branch. I tried with max Key Repeat and min Delay Until Repeat within OS X settings. Although, it is worth mentioning that I am on 10.14 (I don't have access to a computer running 10.12). That in mind, two questions for you...

import javax.swing.*;  

void setup() {
  JFrame frame = new JFrame();  
  JTextArea textArea =new JTextArea("");  
  textArea.setBounds(5, 5, 200, 200);  
  frame.add(textArea);  
  frame.setSize(205,205);  
  frame.setLayout(null);  
  frame.setVisible(true);
}  
hamoid commented 5 years ago

Could it be related to high dpi / retina / font size / external monitor?

sampottinger commented 5 years ago

Ah good call @hamoid! It's the editor font size. Ooopphhh... it looks like its on the java11 branch. I'll look into that.

sampottinger commented 5 years ago

Ah gee... https://github.com/sampottinger/processing/blob/master/app/src/processing/app/syntax/JEditTextArea.java#L621... something must have changed with Swing that is causing this calculation to be different.

sampottinger commented 5 years ago

Hey there! I'll have to take a look at this again later... having a bit of trouble for now. I think it has to do with deprecation in https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/swing/text/Utilities.html re JEditTextArea's _offsetToX but not totally sure. Unfortunately, I think JEdit has moved on from JEditTextArea so we are maybe in the business of updating it ourselves (http://syntax.jedit.org/ looks pretty dead). :-/

P.S. It seems to only happen in some font / size combinations.

hamoid commented 5 years ago

I haven't tried this, but it seems under active development: http://bobbylight.github.io/RSyntaxTextArea/

It seems offer "copy styled" and mouse wheel scrolling (two things that were added to the text editor in the Processing IDE)

I'm curious about how good the autocomplete is. The current autocomplete doesn't work for me sometimes (maybe for objects? I can't remember).

clankill3r commented 5 years ago
  • Do you see the same behavior within mainline processing?

No

  • Do you see the same behavior with a jtextarea (see below)?

No

sampottinger commented 5 years ago

Thanks @clankill3r and @hamoid! (Sigh) It's not a great situation...

I'd prefer to switch out of JEdit Syntax for something like RSyntaxTextArea. For the record: I think the IDE is important for approachability and immediacy of Processing (I believe that the project would be worse off if we only supported processing-java) but I am also worried about JEdit Syntax and think RSyntaxTextArea seems like a good candidate for continuing that into the future. That said, the current code is not posing a clear stability / security issue and is still likely usable with modification. Given that JEdit Syntax has a possible sustainable path forward, I don't know if I (as a community contributor) quite get to make the call to transition libs. That said, I do see that @benfry and @fjenett looked into it at one point (https://github.com/processing/processing/issues/3199). While that work seems to have gone away, I would be willing to look into it again after Ben weighs in...

That in mind, I have found that Source Code Pro has had similar issues in other editors (sublime and XCode). Furthermore, using Swing Utilities, I see that, in the problematic font sizes, the characters have widths with half pixels (*.5) which might be causing trouble with Utilities.getTabbedTextWidth. There isn't a clear contract that Java is violating (I don't think it's a JDK bug per-se) but it seems that there's a lot of code related to size of fonts that isn't graphics context aware ... which might be causing the issue.

Still looking! I'll report back soon.

sampottinger commented 5 years ago

Welp... Looks like I got a fix! :D Still want to chat with Ben about a possible move away from JEdit Syntax later but please see #107.

sampottinger commented 5 years ago

We're merged in! Thanks for your help!

JackTheCat53 commented 3 years ago

Hello, A completely new user downloading just to learn java, however, I am seeing this issue in the 4.0b1 windows release. I tried various fonts and text sizes with different but similar results. I'm going to use the latest release 3 instead for now.