Prepared to move to zoom level being calculated in the platform instead of DPI being returned. This is because zoom level may be distinct from the system DPI and operating systems may report a DPI of 96 while also requesting a display zooming of 125%. Therefore, using the system display scaling is preferred to using DPI after JEP 263.
Refactored ant build chain to allow building / running without execution of tests but ensure tests are run during dist. Note that tests are still runnable under the test target itself. Resolves#8.
Swing now enables the fullscreen option on Mac when a JFrame has setResizable(true). This removes the deprected com.apple.eawt.FullScreenUtilities.setWindowCanFullScreen call for setResizable instead. Resolves#36.
Reflexive access is no longer allowed so we need to transition displayDensity and isRetina to GraphicsConfiguration. As part of this, it's worth noting that other displays outside of OS X may have a retina-like display.
Frustratingly, use of prior Processing WindowsPlatform code for detecting DPI causes UI scaling to turn off and yields a DPI of 96 regardless of windows display scaling. However, in the current WindowsPlatform, UI scaling is enabled but text size calculation within custom rendering swing elements is incorrect, possibly because there is scaling happening underneath transparently. This causes x positions to be inflated at 125% scaling, for example. On a whole, Windows itself does not recommend scaling other than 100% inside the settings UI and that UI scaling within Java itself makes the custom UI elements look bad. So, this suggests disabling the ui scaling in Java for the editor, leaving the opportunity for Processing to find a new way to detect system scaling in the future and handling it internally. At this time, sketches still seem to be calculating positions correctly though they do appear pixelated with display scaling. Therefore, they are left alone.
Discontinued use of string import statement generation and migrated to pdex's ImportStatement class which can keep track of if the import is static or not. This allows static imports to be handled correctly in PDEX, JavaBuild library resoluation, and actual Java compilation step. Resolves https://github.com/processing/processing/issues/5577 and https://github.com/processing/processing4/issues/16 but only in the Processing4 branch.
Per @benfry goal of reducing class count, rolled RewriteParams into PdeParseTreeListener now that the code rewrite utils are also rolled into PdeParseTreeListener.
An explicit goal of @benfry is to reduce class count and this PR cleans up edits made within preproc to merge supporting classes and utility functions of PdeParseTreeListener into PdeParseTreeListener itself. This includes removal of ImportUtil per https://github.com/processing/processing4/issues/10.
A Pottinger