Community
Participate
Working Groups
Build Identifier: As the "open with" functionality has been already implemented (https://bugs.eclipse.org/bugs/show_bug.cgi?id=301030), it would be great if eclipse would register a URL protocol so links to local files can be opened by eclipse. This is especially helpful for web development, where stacktraces are being displayed in the browser, and using a specific url protocol would open the file link in the app which registered the protocol: ie eclipse://open?file=/path/to/file.txt&line=60 For a plugin i've created a workaround for OSX, which simply uses an Applescript that registeres the eclipse:// protocol with Mac OSX and uses applescript to open the file link in eclipse: https://github.com/pulse00/Symfony-2-Eclipse-Plugin/tree/master/org.eclipse.symfony.ui/launcher/osx/symfony2eclipse.app/Contents I think it would be a useful feature if eclipse could handle this natively. Reproducible: Always
updated working link to the applescript: https://github.com/pulse00/Symfony-2-Eclipse-Plugin/tree/master/com.dubture.symfony.ui/launcher/osx/symfony2eclipse.app/Contents
would you accept a patch for this?
Where would be a good place to put this? org.eclipse.ui.cocoa? PW
Right now i don't have an idea ;) i've been extending PDT mainly, but i could have a look into this. If org.eclipse.ui.cocoa is the bundle creating Eclipse.app/Contents/Info.plist, then i'd say it's the right place.
(In reply to comment #4) > > If org.eclipse.ui.cocoa is the bundle creating > Eclipse.app/Contents/Info.plist, then i'd say it's the right place. Things like the Info.plist are created in the launcher fragments (AFAIK). Is it something to do with the application itself that has to register the protocol with the OS (as opposed to a running eclipse instance)? PW
afaik all there needs to be done is to add CFBundleURLTypes to the already existing Info.plist. Here's how it's done in my applescript Info.plist: https://github.com/pulse00/Symfony-2-Eclipse-Plugin/blob/master/com.dubture.symfony.ui/launcher/osx/symfony2eclipse.app/Contents/Info.plist#L24
So there is bug 339526 against p2 (and implicitly against PDE) to allow specifying platform-specific manifests. Robert, do you know how other platforms handle providing URL definitions?
(In reply to comment #7) > So there is bug 339526 against p2 (and implicitly against PDE) to allow > specifying platform-specific manifests. > > Robert, do you know how other platforms handle providing URL definitions? No, unfortunately not. On windows it seems to be handled via the registry: http://msdn.microsoft.com/en-us/library/aa767914%28v=vs.85%29.aspx But i'm not sure about linux.
For now, let's focus on the platforms that Robert knows about and see how we can progress from there.
That would entail something like the patch in 339526 to provide a custom Info.plist. On Linux, the freedesktop.org spec seems to entail installing a set of files into one of /usr/share/mime, /usr/local/share/mime, or ~/.local/share/mime and then triggering update-mime-database. See the sections on Directory Layout and URI scheme handlers at: http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html On Windows, the URI scheme is configured through the Windows registry: http://msdn.microsoft.com/en-us/library/aa767914(v=VS.85).aspx
Created attachment 229686 [details] URL scheme patch for osx
To bring this ticket a little onward i've created a patch which adds the corresponging entries in the .plist files of the rt.equinox.framework project.
I'm looking at creating a custom URL scheme for a Eclipse RCP application. I'm not sure if missing something. But once you get the URL protocol registered with the OS. Shouldn't we react to the OS events when opening a URL? I've noticed that for OS X Bug 178927 extends equinox to listen for kAEOpenDocuments events. On OS X there is a similar event for URLs called kAEGetURL. Bug 201154 also updates SWT PI to listen for kAEOpenDocuments. I think Equinox and SWT PI should be extended to listen for kAEGetURL. But is this tracked in separate bug reports?
Created attachment 237420 [details] Patch for Equinox 3.7 Cocoa to listen for open URL evetns I've created a patch for Equinox 3.7 Cocoa that allows it to listen for open URL events from Mac OS X. I've used bug 178927 as reference, since it implemented support for open file events. The patch requires changes to SWT as well.
Created attachment 237421 [details] Open URL event introduced to SWT 3.7 Cocoa Introduce new SWT.OpenUrl event. And add needed plumbing for Equinox to deliver its Open URL events on OS X Cocoa.
Note the launcher part has been submitted to Gerrit with: https://git.eclipse.org/r/#/c/30030/
(In reply to Mads Tandrup from comment #15) > Created attachment 237421 [details] > Open URL event introduced to SWT 3.7 Cocoa > > Introduce new SWT.OpenUrl event. > And add needed plumbing for Equinox to deliver its Open URL events on OS X > Cocoa. Hi Mads, We are already past API freeze for this (4.5) release. We cannot add any new APIs now. I'll review the SWT patch and evaluate it for Eclipse 4.6.
Sounds great. Apart from the Equinox changes, there's also SWT changes tracked in review https://git.eclipse.org/r/#/c/30107/
I've noticed that both of my Gerrit patches are still open: https://git.eclipse.org/r/#/c/30030/ https://git.eclipse.org/r/#/c/30107/ What can I do to move it forward? Best regards, Mads
Setting target to 4.6M2.
Gerrit change https://git.eclipse.org/r/30030 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=a112b30d15b5e21338cceb8b0dbf53e6cb95d74a
(In reply to Mads Tandrup from comment #19) > I've noticed that both of my Gerrit patches are still open: > https://git.eclipse.org/r/#/c/30030/ > https://git.eclipse.org/r/#/c/30107/ > > What can I do to move it forward? > > Best regards, > Mads Hi Mads, Thanks for the patches. I looked at them and had a few points. 1. The equinox patch doesn't include the changes to Info.plist to register the URL scheme. The patch would not work without that change, right? 2. The patches provide the implementation only for Mac. It's good that we now have the support for one platform. But, the API will be incomplete if don't implement this for the other supported platforms- gtk and windows. Have you investigated the support on them? Do you plan to provide patches for gtk & windows too? 3. I think we should track and discuss the SWT changes in a separate bug. I'll clone this bug. 4. It would we useful for testing purposes if you can describe the exact use-case used for testing the patch. We could also come up with other use-cases to include in testing.
Mass move to 4.7.
Is there any way for an Eclipse plugin to get the URL parameter in the current most-used Eclipse versions 4.1-4.3? I manually registered a custom URL protocol from the info.plist file of Eclipse app in Mac, and I want to acquire the URL parameter when launching Eclipse from the URL. Thanks.
There's an open patch in this bug, that's awaiting response from Madas. @Madas, are you still working on the patch?
I have updated the SWT patch with an implementation for Windows: https://git.eclipse.org/r/#/c/30107/10 Please review.
(In reply to Lakshmi Shanmugam from comment #22) > > 3. I think we should track and discuss the SWT changes in a separate bug. > I'll clone this bug. > Created Bug 525305 to track and discuss the SWT changes. (In reply to Christian Georgi from comment #26) > I have updated the SWT patch with an implementation for Windows: > https://git.eclipse.org/r/#/c/30107/10 > Please review. Thanks for the patch. I've updated the gerrit patch to point to the SWT bug. Can you please provide steps on how to verify the patch on Windows?
From comment#22: Pending item: Changes to Info.plist to register the URL scheme. Are any changes required on Windows/Linux?
(In reply to Lakshmi Shanmugam from comment #28) > From comment#22: > Pending item: Changes to Info.plist to register the URL scheme. > Are any changes required on Windows/Linux? Yes, see comment #8 and comment #10.
New Gerrit change created: https://git.eclipse.org/r/113456
(In reply to Eclipse Genie from comment #30) > New Gerrit change created: https://git.eclipse.org/r/113456 Patch for Info.plist to register eclipse URL scheme.
(In reply to Lakshmi Shanmugam from comment #31) > Patch for Info.plist to register eclipse URL scheme. What is the purpose of the 'eclipse' scheme? Which logic would run if an eclipse:/ link is opened?
(In reply to Christian Georgi from comment #32) > (In reply to Lakshmi Shanmugam from comment #31) > > Patch for Info.plist to register eclipse URL scheme. > > What is the purpose of the 'eclipse' scheme? Which logic would run if an > eclipse:/ link is opened? On Mac, a custom url has to be registered with the OS by specifying it in the Info.plist of the app. For example: open -a /Applications/Eclipse.app eclipse://12345 eclipse://12345 will be treated as a url by Eclipse.app only if it is declared in the Info.plist and registered with the OS. We need to decide if want to create a custom url for eclipse by default or expect users to create one if required. Anyway created a gerrit as it is also required for testing.
(In reply to Lakshmi Shanmugam from comment #33) > We need to decide if want to create a custom url for eclipse by default or > expect users to create one if required. Good point here. Initially I thought about only custom schemes like 'foo:', but we could make the same work with one generic scheme 'eclipse:' whose handler dispatches to more specific handlers, like for 'eclipse:foo:' to the handler contributed by a 'Foo' bundle. This would relief bundles or the platform from providing the protocol registration dance for each OS. There could even be default handlers, like 'eclipse:install:' where P2 would install Eclipse features. This is what VS code does as well (see the links on https://marketplace.visualstudio.com/ like 'vscode:extension/eamodio.gitlens').
(In reply to Christian Georgi from comment #34) > (In reply to Lakshmi Shanmugam from comment #33) > > We need to decide if want to create a custom url for eclipse by default or > > expect users to create one if required. > > Good point here. Initially I thought about only custom schemes like 'foo:', > but we could make the same work with one generic scheme 'eclipse:' whose > handler dispatches to more specific handlers, like for 'eclipse:foo:' to the > handler contributed by a 'Foo' bundle. This would relief bundles or the > platform from providing the protocol registration dance for each OS. > > There could even be default handlers, like 'eclipse:install:' where P2 would > install Eclipse features. This is what VS code does as well (see the links > on https://marketplace.visualstudio.com/ like > 'vscode:extension/eamodio.gitlens'). According to https://tools.ietf.org/html/rfc3986#section-3.1 ":" are not allowed in URL schemes. This rfc says that schemas should follow the following grammar: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) We should consider this when going for the generic "eclipse"-approach.
(In reply to Matthias Becker from comment #35) > > According to https://tools.ietf.org/html/rfc3986#section-3.1 > ":" are not allowed in URL schemes. This rfc says that schemas should follow > the following grammar: > > scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) > > We should consider this when going for the generic "eclipse"-approach. But also above that section there is this description: The following are two example URIs and their component parts: foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / \ urn:example:animal:ferret:nose 'eclipse' is the scheme. That scheme would define what the remainder of the URI syntax. If the 'eclipse' scheme simply allows another embedded URI then I think that is fine. Similar to the 'jar' scheme in Java.
(In reply to Christian Georgi from comment #34) > (In reply to Lakshmi Shanmugam from comment #33) > > We need to decide if want to create a custom url for eclipse by default or > > expect users to create one if required. > > Good point here. Initially I thought about only custom schemes like 'foo:', > but we could make the same work with one generic scheme 'eclipse:' whose > handler dispatches to more specific handlers, like for 'eclipse:foo:' to the > handler contributed by a 'Foo' bundle. This would relief bundles or the > platform from providing the protocol registration dance for each OS. > > There could even be default handlers, like 'eclipse:install:' where P2 would > install Eclipse features. This is what VS code does as well (see the links > on https://marketplace.visualstudio.com/ like > 'vscode:extension/eamodio.gitlens'). The "eclipse" schema fits perfectly e.g. for the marketplace client to install new features. But for other stuff I don't think that this is a good idea. You should never put parts of the technology into the URL. The URL for our plugins (that provide support for SAP programming language ABAP) is adt: (for ABAP Development Tools). What if SAP decides in the future to move away from Eclipse and to move to IntelliJ (like the Android tooling did). In such a case the eclipse:adt: URLs would brake. A adt: URL would not break (cool URIs don't change!). The ABAP tooling in IntelliJ would simply also provide a link handler for the adt: scheme. The user could then decide if the Eclipse based or the IntelliJ based tooling should be used.
Right, that's the downside of IDE-specific URLs. This means we should prepare the platform for individual bundles' contribution of URL schemes.
(In reply to Christian Georgi from comment #38) > Right, that's the downside of IDE-specific URLs. This means we should > prepare the platform for individual bundles' contribution of URL schemes. I think there is a problem to be addressed on Mac -- the custom url has to be declared in the Info.plist for OS to recognize it as a custom url for eclipse. So, plugins that contribute a URL scheme will be have to update the Info.plist as well.
(In reply to Lakshmi Shanmugam from comment #39) > I think there is a problem to be addressed on Mac -- the custom url has to > be declared in the Info.plist for OS to recognize it as a custom url for > eclipse. So, plugins that contribute a URL scheme will be have to update the > Info.plist as well. That's indeed an issue to address: 1. Either let plugins mess with Info.plist all by custom code. Probably worst solution. 2. Let P2 do it through a new advice at plugin installation time (see bug 339526). Would work nicely on MacOS, but fails for the registry entries on Windows. There, we need the absolute path to the installation in the registry, which P2 does not know in case of prebuilt packages (like the download packages on eclipse.org). 3. Or have code in the platform/workbench to register all known schemes. Not sure though when the code should run (startup? on request by the user?) This would be the solution to cover all OSes, since the running platform has all the knowledge to properly register itself on Mac, Windows, and Linux.
Gerrit change https://git.eclipse.org/r/30107 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=247d7f9a4fdc740d6f8a82838c37cd93fd029b14
Please note, the linux part was also implemented/merged: 525305 – [API]Provide SWT.OpenUrl event https://bugs.eclipse.org/bugs/show_bug.cgi?id=525305 In Linux it works like: eclipse http://url E.g, in Firefox one can link protocols to open with eclipse like: (not tested but in theory): about:config network.protocol-handler.external.git = true network.protocol-handler.app.git = eclipse %s network.protocol-handler.expose-all = true [1] http://kb.mozillazine.org/Register_protocol
