| Requirements to use FXCanvas in Eclipse plugins? [message #1766631] |
Fri, 23 June 2017 15:51  |
Eclipse User |
|
|
|
I'm wondering what bundle I'm supposed to depend on currently in order to have access to javafx.embed.swt.FXCanvas...
I'm currently in the process of switching a plugin from depending on a customized version of SWT_AWT + Albireo (removing the deadlock-prone assumption that one of the two UI threads can safely lock on the other) to instead using FXCanvas + SwingNode to display Swing components in Eclipse.
I gather, from what I've seen, that classloading FXCanvas is a bit complicated in osgi, but I was happy to see that you had put out an orbit bundle (org.eclipse.fx.javafx) that we could depend on to make sure it was available...but now it seems you've deprecated that bundle, as I'm seeing a warning to that effect when I debug my plugin.
I'm seeing suggestions that the plugin dependency should be replaced with the VM argument -Dorg.osgi.framework.bundle.parent=ext
...is that command-line argument sufficient for all Eclipse installations, regardless of whether e(fx)clipse is installed, or is there a p2 orbit bundle that we must also depend on?
Is it necessary to require our customers to modify their Eclipse.ini by hand if we switch to using FXCanvas?
|
|
|
|
| Re: Requirements to use FXCanvas in Eclipse plugins? [message #1768698 is a reply to message #1766938] |
Fri, 21 July 2017 18:30  |
| Eclipse User |
|
|
|
We do gain something from the exercise, because SWT/AWT is responsible for the deadlocks, it blocks one UI thread on another, which is not safe because they lock the same native resources.
Our version that removes those deadlocks and integrates the abandoned Albireo improvements has its own issues. Java's own SwingNode class is a big improvement over SWT/AWT: it has the right level of access to Swings internals to be able to get things right without (as?) weird hacks, and they made the right assumption, that all communication between the two UI threads must be asynchronous, unlike SWT/AWT.
Of course, one still has to keep in mind that it's a multi-threaded UI, and be sure to never block from one UI thread on the other (which even requires odd things like never checking whether you're on the AWT thread from the SWT thread), but with the right thread-switching tools it's possible to embed Swing in SWT via FX.
So the change was that org.eclipse.fx.javafx is replaced by org.eclipse.fx.osgi? Thanks!
[Updated on: Fri, 21 July 2017 18:44] by Moderator Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.03596 seconds
] 
Search
Help
Register
Login
Home
