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

Adding a Gradle Build system to the Processing IDE #888

Open
wants to merge 95 commits into
base: main
Choose a base branch
from

Conversation

Stefterv
Copy link
Collaborator

@Stefterv Stefterv commented Dec 14, 2024

Here's the first pull-request adding a new Gradle build system to the Processing IDE.

The GitHub Actions will create distributable binaries for macOS (x64, aarch64), windows (x64) and linux (x64). The other platforms will need their own CI/CD system, but I think the repo will already build on the other platforms.

In terms of compatibility I've come pretty far but I'm sure there is some functionality that I have missed.

To test

  • Examples
  • Tweaks mode
  • P2D
  • Debugger
  • Languages
  • Contributed libraries
  • Autocomplete
  • MovieMaker
  • Exporting Applications
  • processing-java
  • java mode default libraries (dxf,svg,io,net,serial,pdf)
  • Python mode (BROKEN, already on 4.3.1 macOS aarch64)
  • Android mode

To add

New Features

  • Installers for macOS (dmg), Widows (msi), linux (deb)
  • Windows: Start menu item
  • Jetpack Compose
  • Kotlin Support for the IDE
  • Splash screen Refactor + Animation

To improve

  • Legacy resource handling (rn it copies all assets to temp folder on launch)
  • Move all dependencies to libs.versions.toml
  • Version and Build number

After Pull Request

To consider

  • Appstores

In any case, this pull request does not break the existing Ant build system so we can either wait with the merge or we can have the Gradle version available as a preview.

The bundle size has increased quite a bit since we are shipping a JRE and a JDK instead of using the JDK to run the IDE
|linux-x64 | 257 MB |  
|macos-aarch64 | 294 MB |  
|macos-x64 | 289 MB |  
|windows-x64 | 275 MB |

P.S. this also includes the pre-processor as a Maven library, so merging this PR will add processing:java:prepocessor as a Maven package

@Stefterv
Copy link
Collaborator Author

compose desktop does not support Raspberry PI 32-bit, which would mean models older than 3B would become unsupported. The raspi 2 was released in 2015 and I'm not sure how well it would run Processing in any case, so could that be an argument to drop support for it?

@Stefterv
Copy link
Collaborator Author

Another long term consideration I found is that compose desktop does not support building for another OS than the currently running one. For the IDE that is fine as we can use GitHub Actions. For exporting sketches this might be a bit limiting for users of Processing. I'd love to use the same packager within both contexts but we might have to use a different one for exporting sketches.

@SableRaf
Copy link
Collaborator

compose desktop does not support Raspberry PI 32-bit, which would mean models older than 3B would become unsupported. The raspi 2 was released in 2015 and I'm not sure how well it would run Processing in any case, so could that be an argument to drop support for it?

Sounds reasonable. We should communicate this early and gather community feedback. Could you draft an issue to explain the rationale for dropping 32-bit Raspberry Pi support? I'll share it on Discord, Discourse, and social media to request comments. Let me know if I can help in other ways.

@SableRaf
Copy link
Collaborator

SableRaf commented Dec 17, 2024

I'd love to use the same packager within both contexts but we might have to use a different one for exporting sketches.

Thanks for flagging this. What would be the consequences of this approach? Larger download? Other limitations? Could we consider releasing platform-specific build support as tools/libraries? A bit like Unity does it?

@Stefterv
Copy link
Collaborator Author

Thanks for flagging this. What would be the consequences of this approach? Larger download? Other limitations? Could we consider releasing platform-specific build support as tools/libraries? A bit like Unity does it?

Consequences are not really clear for now as we're not really trying to do anything special while bundling. Which means we're also pretty flexible in terms of which bundler we use.

If we in the future would like to add composable UI's to Processing sketches for example, then we might need some of the functionality of the bundler that the IDE uses.

@Stefterv
Copy link
Collaborator Author

Stefterv commented Dec 18, 2024

Screen.Recording.2024-12-18.at.09.14.01.mov

Little preview of the new splash screen and the tweak to the macOS titlebar

Before

Screen.Recording.2024-12-18.at.09.16.56.mov

@@ -460,8 +460,9 @@ public void testMultilineStringClass() {

@Test
public void testMultiMultilineString() {
Preferences.setBoolean("export.application.fullscreen", true);
expectGood("fullscreen_export");
// TODO: Add support for fullscreen. Not through settings. In PdeParseTreeListener.java
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be re-enabled I think, it's been fixed

errStr = DefaultErrorLocalStrSet.get().get("editor.status.error.syntax").orElse("Error");
retStr = DefaultErrorLocalStrSet.get().get(stringName).orElse(stringName);
}
var errStr = DefaultErrorLocalStrSet.get().get("editor.status.error.syntax").orElse("Error");
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still not sure how to fix this

new File(resourcesFolder, "en.lproj"));
Util.copyFile(mode.getContentFile("application/application.icns"),
new File(resourcesFolder, "application.icns"));
// TODO: Handle the java embed and Icon with the new build system
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO

// Default installation paths for different operating systems
if (os.contains("windows")) {
var programFiles = new File(System.getenv("ProgramFiles"));
return new File(programFiles, "Eclipse Adoptium/jdk-17.0.10+7-hotspot");
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if hardcoded JDK-17 is still relevant

The Processing Website has more meta-data related to the examples. I'd like to use that meta-data going forward so I've added it
@Stefterv
Copy link
Collaborator Author

Stefterv commented Dec 18, 2024

Screen.Recording.2024-12-18.200843.mp4

Windows adjusted titlebar

Suhailmo99
Suhailmo99 previously approved these changes Dec 18, 2024
@SableRaf SableRaf dismissed Suhailmo99’s stale review December 19, 2024 07:06

This PR is not ready for review.

Using the work by @mingness to simplify the contributions workflow.
Disabled the post request because that data is not saved anywhere and most hosts do not support it
@Stefterv Stefterv added this to the pde-gradle milestone Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In progress
Development

Successfully merging this pull request may close these issues.

3 participants