Eclipse Community Forums: Eclipse Platform » URI Scheme handler without SWT

Help

Home

Home » Eclipse Projects » Eclipse Platform » URI Scheme handler without SWT

Show: Today's Messages :: Show Polls :: Message Navigator

URI Scheme handler without SWT [message #1832248]

Mon, 14 September 2020 09:15

Aleksei Airapetov

Messages: 13
Registered: December 2019

Junior Member

Hello,

I have an RCP Application which however uses JavaFX for UI.
What I need to do is to handle custom URI scheme calls on macOS (the way you handle it on macOS differs from another OSs where URL is sent to application as program argument).

I found out that Eclipse has its mechanism for registering and handling URI scheme calls and it also provides extension point for plugins to define their own schemes.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835

If I understand correctly how this works under the hood for URI scheme calls handling, equinox launcher somehow handles URI scheme calls and then passes URL to org.eclipse.swt.widgets.Display class which then generates SWT.OpenUrl event. (assumption based on gerrit changes of this bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=351303).

Equinox launcher is used in my application, SWT however is not.
So is there some way to handle open URL events and not importing whole SWT?
An option comes to mind that implies "re-inventing" the functionality of the Display class to receive events from the Equinox launcher. Is it possible?
Or maybe it is possible to import some minimal set of SWT packages to provide functionality for handling URI schemes (but not importing the whole SWT which can significantly affect the size of the app
)?

Report message to a moderator

Re: URI Scheme handler without SWT [message #1832276 is a reply to message #1832248]

Tue, 15 September 2020 07:03

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

I see you've done significant homework!

I've also implemented support for the Eclipse Installer to exploit this mechanism:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=551315

One problem I had there is that the preference support in the platform depends on there being a workbench, which is not present for the installer. I imagine if you don't use SWT you don't have a workbench either...

I also didn't like that one could override an existing registration, but that's since been changed...

I found this blog quite useful to describe how the launcher behaves:

http://aniefer.blogspot.com/2010/05/opening-files-in-eclipse-from-command.html

Of course an important behavioral aspect is whether the launcher actually launches a new application or instead finds an existing running application, sending it an event. This behavior definitely depends on the Display (and I don't believe it works quite right on Linux where trying to launch the installer ends up sending an event to an actual Eclipse IDE application if one is already running, even though I got all the application name stuff correct such that it works correct on Windows and Mac).

I don't think you'll be able to re-implement this support with a different Display implementation and trying to implement your own native launchers would also be a huge challenge.

Are you looking to have your already running application handle URLs?

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: URI Scheme handler without SWT [message #1832303 is a reply to message #1832276]

Tue, 15 September 2020 18:25

Aleksei Airapetov

Messages: 13
Registered: December 2019

Junior Member

Thanks for the information! The blog was especially useful for understanding how it works.

Well, the problem is I need both cases for my URI handler - when application is already running and when it was launched by URI scheme call either.

I also tried approach with using this method of java.awt.Desktop class
https://docs.oracle.com/javase/10/docs/api/java/awt/Desktop.html#setOpenURIHandler
which however has known bug with not recieving URL when application was launched by URI scheme call
https://bugs.openjdk.java.net/browse/JDK-8198549

With a simple check I realized Eclipse doesn't suffer from such an error, too bad it will be hard to apply its mechanism for my application without using SWT.

Report message to a moderator