Skip to content

Add all seven of the javafx modules to JavaBuild.java #856

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

Merged
merged 4 commits into from
Nov 17, 2024

Conversation

vsquared
Copy link
Contributor

Please add _all seven of the javafx modules so that we may use JavaFX controls in our apps. Thanks.

Please add _all seven of the javafx modules so that we may use JavaFX controls in our apps. Thanks.
@hx2A
Copy link
Collaborator

hx2A commented Nov 16, 2024

I'd like to second this. This change would also make it much easier to use JavaFX with py5.

@SableRaf SableRaf requested a review from Stefterv November 16, 2024 23:05
@SableRaf SableRaf changed the title Update JavaBuild.java Add all seven of the javafx modules to JavaBuild.java Nov 16, 2024
@SableRaf
Copy link
Collaborator

Hi @vsquared and thanks for your suggestion. It looks like the current commit just adds a file to the root of the repository with instructions for modifying JavaBuild.java, instead of directly making the change in the file. Could you update the PR to modify JavaBuild.java directly instead so we can properly review the proposed changes?

@vsquared
Copy link
Contributor Author

vsquared commented Nov 17, 2024

After modifying two different Processing editors with the above change my observation is that adding the seven javafx jar files to the sketch folder is no longer necessary. I have no experience using javafx in IntelliJ or testing on a platform other than macos. My impression is that adding all the jar files to the sketch folder sometimes fails when trying to run javafx code in an editor that has not been modified. I cannot be 100% certain about this and it needs further study. Nevertheless, I don't think the average user wants to go to all the bother to find the seven jar files and copy them to the sketch folder just to run a javafx demo. It would be easier for everyone if a simple one line change was made to the editor. I know this works for macos, but have not tried it on Windows or Linux.
Addendum:
Processing 4.3 failed to run a javafx app with all seven jar files in sketch folder, either lying free or inside a 'code' folder. Another copy of a Processing 4.3 editor modified with the changes above will run the javafx demo without the addition of jar files.
Processing 4.3.1 on macos also failed to run a javafx app with all seven jar files in the sketch folder, both lying free and inside a 'code' folder.

@vsquared
Copy link
Contributor Author

vsquared commented Nov 17, 2024

@SableRaf - I did another fork of the main app and edited the JavaBuild.java file and submitted a second pull request.

Please add _all seven of the javafx modules so that we may use JavaFX controls in our apps. Thanks.
Copy link
Collaborator

@Stefterv Stefterv left a comment

Choose a reason for hiding this comment

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

Hi @vsquared,

Please change the things I marked, I will now look into the JavaFX examples provided and see if they work

Looking at the context of this change as something specific and limited to existing cases handling JavaFX code I think it would probably be fine. I just need to test and understand your use case

@Stefterv
Copy link
Collaborator

Tested on windows, does indeed fix the issue you're describing, so happy to merge after the requested changes.
If you can find a user friendly way, e.g. not just adding the JavaFX jars to the code folder, please let me know. I would like to make that possible.

Please add _all seven of the javafx modules so that we may use JavaFX controls in our apps. Thanks.
@Stefterv
Copy link
Collaborator

Cool thanks @vsquared!

I'll let you hit the merge button @SableRaf

@vsquared
Copy link
Contributor Author

@Stefterv - If you can find a user friendly way, e.g. not just adding the JavaFX jars to the code folder, please let me know. I would like to make that possible.
On macos if you make the changes I suggested the user should not need to add the jar files to the sketch folder.

@SableRaf SableRaf merged commit 9292eb5 into processing:main Nov 17, 2024
6 checks passed
@vsquared vsquared deleted the patch-1 branch November 17, 2024 14:22
@vsquared
Copy link
Contributor Author

vsquared commented Feb 4, 2025

@Stefterv Pull Request Followup: Thank you for adding the pull request changes. After the last release of the Processing IDE (v. 4.3.2) I have been able to run JavaFX demos on MacOS without adding a 'code' folder to the sketch or modifying/recompiling the editor as I was doing in the past. Because of this success I have started posting new JavaFX demos in the Forum with the anticipation that other users would be able to run them too. Unfortunatey this has not been the case for Windows or Linux users, as discussed here: https://discourse.processing.org/t/processing-and-javafx/45692/6 . They are able to run JavaFX demos, but only after creating a 'code' folder either by drag 'n dropping all seven of the JavaFX jar files onto an open sketch window or manually copy/pasting the jar files which are not easy to find in the 'libraries' folder. It appears that the Processing IDE correctly installs the JavaFX jar files but does not know that they are there and therefore unable to use them. It also appears that this is a known problem and is on the TODO list to fix. I'm willing to help track this down if I know where to start, but I am not a skilled Windows or Linux programmer. I do have Windows 11 and Linux PopOS systems which are rarely used but could be used for testing. Do you have any advice on where to start looking to solve this problem? I appreciate your time and efforts.

@SableRaf
Copy link
Collaborator

SableRaf commented Feb 11, 2025

Hi @vsquared. Thanks for your follow-up and for testing on different platforms.

For the JavaFX compatibility issue specifically, I recommend opening a new issue, clarifying the current and intended behavior, as well as any proposed solution(s).

Note: Right now, our main focus is the Gradle migration, which is a major effort with very limited capacity (mostly just @Stefterv working on it). Long term, we are looking at moving away from JOGL and abstracting the renderer—this is part of the roadmap (see issue #881). If you have any thoughts on that and how JavaFX may support that goal, feel free to contribute to the discussion over there.

Appreciate your patience and contributions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants