Community
Participate
Working Groups
Build Identifier: I would like to open a link to a URL like "abc://foo" in Eclipse. The existing open URL implementation in DelayedEventsProcessor, however, is restricted to local files since it uses EFS.getLocalFileSystem(). If we used EFS.getStore(URI) instead, this would support arbitrary URLs out of the box. One would just need to implement a minimal EFS file store for the respective URL scheme. The existing file URLs would then just be special instance of this implementation. Reproducible: Always
Since there does not seem to be any interest in the topic so far, let me rephrase what we are trying to achieve and where the challenges are. We have used links with custom URL schemes in a commercial tool for quite some time now, and they have proven to be a really flexible means to link to Eclipse. Some usage scenarios are: - Linking from an object within a legacy, non-Eclipse tooling right into the very same object in Eclipse. This is how we make it easier for users of the legacy to get into Eclipse without losing context, especially in ad-hoc use cases. - Linking from objects named in external documents into the "real code" in Eclipse, thus bridging the gap from traditionally decoupled and over time aging documentation. I am wondering who else also has such scenarios. Imho Eclipse as a platform would benefit from a better handling of custom URLs. While we got custom URL schemes running with some hacks in a custom Eclipse product, we are stuck with getting it running smoothly in a standard product like the Eclipse SDK. Reason is that the way Eclipse handles OpenDocument events only targets local files (using EFS' local file system), but does not consider any other contributed URL schemes. The story for the user ends immediately after Eclipse has started with an error dialog stating that URL abc://.. cannot be opened. This is why I propose a new extension point that allows for registering custom URL handlers based on a a URL pattern like a URL scheme. On arrival of an OpenDocument event IDEApplication dispatches the event to the correct handler. The existing local file support in DelayedEventsProcessor can be rewritten as a handler for "file:" URLs. Quite simple actually, and I already have a working prototype. However, some questions remain: - Where should this API be contained? In a place near IDEApplication, which today hooks up the OpenDocument listener? Or should it go into generic workbench so that all RCP apps can make use of it? - Have I missed any other functionality in the workbench that does similar things and should be enhanced with this URL handling instead? Any suggestions are welcome.
