Merge branch 'processing:master' into issue_353_fix

Author: codeanticode

build/build.xml

@@ -78,6 +78,7 @@
  </fail>
 
  <fileset dir="macos/work/Processing.app/Contents" id="jdk-optional-macos">
+ <!-- src.zip is 52 MB and we absolutely do not need it -->
  <include name="PlugIns/jdk-${jdk.detail}+${jdk.build}/Contents/Home/lib/src.zip" />
  </fileset>
 
@@ -139,8 +140,11 @@
  </or>
  </condition>
 
- <!-- Java 17.0.1 via Adoptium -->
+ <property name="jdk.download.dist" value="jdk" />
+ <!-- JRE? https://github.com/processing/processing4/issues/365 -->
+ <!-- <property name="jdk.download.dist" value="jre" /> -->
 
+ <!-- Java 17.0.1 via Adoptium -->
  <!--
  https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.1%2B12/OpenJDK17U-jre_x64_mac_hotspot_17.0.1_12.tar.gz
  https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.1%2B12/OpenJDK17U-jre_aarch64_mac_hotspot_17.0.1_12.tar.gz
@@ -149,7 +153,7 @@
  https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.1%2B12/OpenJDK17U-jdk_arm_linux_hotspot_17.0.1_12.tar.gz
  https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.1%2B12/OpenJDK17U-jdk_aarch64_linux_hotspot_17.0.1_12.tar.gz
  -->
- <property name="jdk.download.url" value="https://github.com/adoptium/temurin17-binaries/releases/download/jdk-${jdk.detail}%2B${jdk.build}/OpenJDK17U-jdk_${jdk.download.arch}_${jdk.download.os}_hotspot_${jdk.detail}_${jdk.build}.${jdk.download.ext}" />
+ <property name="jdk.download.url" value="https://github.com/adoptium/temurin17-binaries/releases/download/jdk-${jdk.detail}%2B${jdk.build}/OpenJDK17U-${jdk.download.dist}_${jdk.download.arch}_${jdk.download.os}_hotspot_${jdk.detail}_${jdk.build}.${jdk.download.ext}" />
 
  <get src="${jdk.download.url}"
  dest="${jdk.archive.path}"
@@ -465,7 +469,8 @@
  <arg value="../${jdk.archive.path}"/>
  </exec>
 
- <property name="jdk.dir" value="macos/work/jdk-${jdk.detail}+${jdk.build}.jdk/" />
+ <!-- does not appear to be in use -->
+ <!-- <property name="jdk.dir" value="macos/work/jdk-${jdk.detail}+${jdk.build}.jdk/" /> -->
 
  <!-- https://github.com/processing/processing4/issues/284 -->
  <copy file="macos/appbundler-${os.arch}.jar"
@@ -495,9 +500,9 @@
  anything else outside /jdk) from the full JDK, even though
  it's primarily copying over the JRE folder. -->
  <runtime dir="${jdk.path.macos}/Contents/Home" />
- <!-- Eventually we'll want to load the JRE directly from
-  the .tgz on the Oracle site, though it's in a folder called
-  jdk1.7.0_40.jdk, so we'll need to strip that out. -->
+
+ <!-- use JRE https://github.com/processing/processing4/issues/365 -->
+ <!-- <runtime dir="${jdk.path.macos}-jre/Contents/Home" /> -->
 
  <!-- Same as runtime.jars, seen above; plus core.jar. -->
  <classpath file="../app/pde.jar" />
@@ -740,14 +745,15 @@
  <!-- codesign can't work inside jars? so instead temporarily unpack the files
  that contain dylib entries, just before doing our big signing event -->
 
+ <!--
  <property name="unpack.jogl" value="macos/work/Processing.app/Contents/Java/core/library/jogl-all-natives-macosx-universal" />
+ <unzip src="${unpack.jogl}.jar" dest="${unpack.jogl}" />
 
  <property name="unpack.gluegen" value="macos/work/Processing.app/Contents/Java/core/library/gluegen-rt-natives-macosx-universal" />
+ <unzip src="${unpack.gluegen}.jar" dest="${unpack.gluegen}" />
+ -->
 
  <property name="unpack.jssc" value="macos/work/Processing.app/Contents/Java/modes/java/libraries/serial/library/jssc" />
-
- <unzip src="${unpack.jogl}.jar" dest="${unpack.jogl}" />
- <unzip src="${unpack.gluegen}.jar" dest="${unpack.gluegen}" />
  <unzip src="${unpack.jssc}.jar" dest="${unpack.jssc}" />
 
  <!-- <unzip src="macos/work/Processing.app/Contents/Java/modes/java/libraries/serial/library/jssc.jar" dest="macos/work/Processing.app/Contents/Java/modes/java/libraries/serial/library/jssc" /> -->
@@ -786,13 +792,17 @@
  </apply>
 
  <!-- re-package the jar files after signing their macOS contents -->
+ <!--
  <zip destfile="${unpack.jogl}.jar" basedir="${unpack.jogl}" />
  <zip destfile="${unpack.gluegen}.jar" basedir="${unpack.gluegen}" />
+ -->
  <zip destfile="${unpack.jssc}.jar" basedir="${unpack.jssc}" />
 
  <!-- delete the temporary directories w/ the jar contents -->
+ <!--
  <delete dir="${unpack.jogl}" />
  <delete dir="${unpack.gluegen}" />
+ -->
  <delete dir="${unpack.jssc}" />
 
  <!-- sign the outer application, now that we've finished all the contents -->

build/macos/.gitignore

@@ -1,3 +1,4 @@
 jdk-17*
 processing-*.dmg
 work
+appbundler.jar

core/todo.txt

@@ -1,11 +1,11 @@
 1279 (4.0b4)
 X put opengl libs for core into platform-specific subfolders
 X get us ready for other platforms (M1 in particular)
-_ fixes Windows antivirus slowdowns
-_ https://github.com/processing/processing/issues/4783#issuecomment-269328168
-_ https://github.com/processing/processing/issues/4239
-_ https://jogamp.org/bugzilla/show_bug.cgi?id=1301
-_ https://stackoverflow.com/a/51100411
+X fixes Windows antivirus slowdowns
+X https://github.com/processing/processing/issues/4783#issuecomment-269328168
+X https://github.com/processing/processing/issues/4239
+X https://jogamp.org/bugzilla/show_bug.cgi?id=1301
+X https://stackoverflow.com/a/51100411
 
 api changes (in previous releases)
 X static versions of selectInput/selectOutput/selectFolder removed from PApplet
@@ -28,6 +28,9 @@ o setting up deps for it with projects that don't use it is a headache
 X just not possible
 X PShader would have to change packages
 X that much messier to link back with projects that rely on JOGL
+o would really be nice to pull out the OpenGL stuff
+o though would require just a single PShader class in .opengl package
+o way too messy, just need to stick with our base platforms
 
 regressions
 X PShape doesn't allow attibutes of int type anymore
@@ -49,28 +52,31 @@ _ could implement this for the default, but also, SansSerif sucks
 _ https://stackoverflow.com/a/9482676
 _ in addition, it would need to be implemented for textWidth()
 
-_ would really be nice to pull out the OpenGL stuff
-_ though would require just a single PShader class in .opengl package
-_ way too messy, just need to stick with our base platforms
-
 _ Better solution for frame/surface methods
 _ should it be requestSize() because the change is not immediate?
 _ do we need a windowResized() event?
 _ https://github.com/processing/processing4/issues/53
+_ windowTitle(), windowLocation(), windowSize()
+_ windowResizable(), windowRatio()
 _ setting surface size needs to happen outside draw()
 _ surface.setSize() sadness etc
 _ https://github.com/processing/processing4/issues/162
 _ https://github.com/processing/processing4/issues/186
 _ https://github.com/processing/processing/issues/4129
+_ same goes for window resize events: queue them for when it's safe
+_ also probably need to be extending the display with the background color
+_ so that it's not neither stretching the viewport temporarily
+_ or leaving a gap at the edge of the window
+_ why does GL flash red when resizing?
+_ this may be because of gaps between EDT and updates
+_ fixing the surface.setSize() issue may fix it
 
 _ fullScreen() not working on a second display with P2D or P3D
 _ https://github.com/processing/processing4/issues/352
 
 _ update P2D reference to make clear about drawing order and quality
 _ https://github.com/processing/processing/issues/5880
 
-_ why does GL flash red when resizing?
-
 
 load/save image
 _ https://github.com/processing/processing4/wiki/Exorcising-AWT

todo.txt

@@ -30,8 +30,20 @@ X fixed with https://github.com/processing/processing4/commit/1a49263a94a2d7af
 platforms/variants/export
 X replacing macosx with macos in prefs and languages
 X major rewrite of Export to Application for the six supported platforms
-_ now writes folders with different names instead of 'application.'
+X now writes folders with different names instead of 'application.'
 X move build/macosx to build/macos and make other necessary changes
+X final supported platforms
+X as far as adoptium is concerned:
+X macos-x64, macos-aarch64 (m1), windows-x64, linux-x64, linux-arm32 (rpi)
+X release files: macosx -> macos, linux64 -> linux, windows64 -> windows
+X or macos-intel64, macos-applesi, linux-intel64, ...
+X what should macos-aarch64 be called?
+X Export Application can use nicer names, the libs thing is trickier
+o macosx vs macosx64 in JavaFX
+o the latter is making the export fail because it won't embed a Java VM
+o may be because it's exporting twice and overwriting?
+o or 64 takes precedence?
+X doesn't matter with things being redone
 
 windows scaling
 X Fix "Could not delete disable_hidpi" message on macOS/Linux after closing prefs
@@ -227,15 +239,17 @@ _ docs are 3.x not 4.x
 _ Apple Silicon support
 _ https://github.com/processing/processing4/issues/128
 _ appbundler broken when built on something later than Mojave
-_ also need separate versions because the Monterey build won't run on x86_64
 _ https://github.com/processing/processing4/issues/284
+_ also need separate versions because the Monterey build won't run on x86_64
+_ https://github.com/processing/processing4/issues/364
 _ clean up dist: 'bin' and 'src' from Java Mode are included, iml files, etc
 _ loadShape(), show a warning when using style instead of presentation attributes
 _ Welcome screen or not?
 _ set a new preference for it, so people see it
 _ just skip the welcome screen on Windows hidpi dipslays?
 _ better to launch a web browser
 _ also use id/ask for login to help understand community?
+_ tell users about JavaFX, Movie Maker install, changing themes
 _ change help menu links to go to newer FAQ and the rest
 _ better means of understanding Library/Mode/Tool usage
 _ jeditsyntax is a mess of old-style getModifiers()
@@ -251,17 +265,8 @@ _ or at least avoid the multiple
 
 platforms
 _ https://github.com/processing/processing4/wiki/Supported-Platforms
-_ final supported platforms
-_ as far as adoptium is concerned:
-_ macos-x64, macos-aarch64 (m1), windows-x64, linux-x64, linux-arm32 (rpi)
-_ release files: macosx -> macos, linux64 -> linux, windows64 -> windows
-_ or macos-intel64, macos-applesi, linux-intel64, ...
-_ what should macos-aarch64 be called?
-_ macosx vs macosx64 in JavaFX
-_ the latter is making the export fail because it won't embed a Java VM
-_ may be because it's exporting twice and overwriting?
-_ or 64 takes precedence?
-_ Export Application can use nicer names, the libs thing is trickier
+_ update JavaFX to use the supported platforms
+_ update Video library to use the new layout
 
 
 decisions before final 4.0 release