-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
Conversation
Please add _all seven of the javafx modules so that we may use JavaFX controls in our apps. Thanks.
I'd like to second this. This change would also make it much easier to use JavaFX with py5. |
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 |
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. |
@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.
There was a problem hiding this 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
Tested on windows, does indeed fix the issue you're describing, so happy to merge after the requested changes. |
Please add _all seven of the javafx modules so that we may use JavaFX controls in our apps. Thanks.
@Stefterv - |
@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. |
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! |
Please add _all seven of the javafx modules so that we may use JavaFX controls in our apps. Thanks.