Fix REG_APP_DIR to support jpackage application launchers - #1528
Fix REG_APP_DIR to support jpackage application launchers#1528tutimura-kg wants to merge 3 commits into
Conversation
Sorry, something went wrong.
|
The launcher executable created with jpackage continues to run as a process, so we can easily obtain the executable using ProcessHandle.current().info().command().orElse(null). We can make use of it. In this case, during debugging (launched by gradlew run), it will be ...\java.exe, so we will still need to substitute it with the current directory. |
Sorry, something went wrong.
|
Thanks @tutimura-kg. I am currently doing some fixes to the build system so we can commence releases again. Will review your work after that. |
Sorry, something went wrong.
|
@tutimura-kg okie! the build system is fixed. i will review soon :) |
Sorry, something went wrong.
|
Ok, I'll be waiting. |
Sorry, something went wrong.
Description
This PR fixes an issue where the file association fails when Processing is packaged and launched using jpackage.
Currently, REG_APP_DIR relies directly on System.getProperty("user.dir"). However, when launched via a jpackage generated launcher, user.dir points to the directory from which the application was invoked (e.g., the current terminal directory or shortcut location), rather than the actual installation directory of processing.exe. This causes incorrect registry paths to be registered in checkAssociations().
Thus, launching via file association breaks the next launch via file association. And launching via shortcut fixes the file association. This has not surfaced as a major issue on Windows 11 because the File Manager can override registry-defined associations. However, it remains a hidden bug that this PR aims to fix.
Changes
This ensures that file associations (.pde, etc.) always register the correct absolute path of processing.exe, regardless of the working directory at launch.