Community
Participate
Working Groups
Eclipse Help has the "internal" executeCommand(...) JavaScript function built-in to trigger commands from inside internal Eclipse Help. However, this doesn't work when using Help externally. We could imagine Eclipse providing a handler for eclipse+command:// and allowing to register it with the OS. Then, help could be switched to this new URI form and when using Help from external web browser, the eclipse+command:// URI will be handled by the Eclipse IDE, detected by OS, starting or showing the Eclipse IDE and then running the command. This eclipse+command:// URI handler could also be used to replace other formats like links in welcome page or to simplify integration with some JS-based UIs in RCP apps.
Would this impose an security issue? Could some 'bad' code be executed/inserted from any page opened in the browser? Having such an URI handler for inside Eclipse could be useful though.
(In reply to Rolf Theunissen from comment #1) > Would this impose an security issue? Could some 'bad' code be > executed/inserted from any page opened in the browser? Good point. So the URI handler should show a confirmation message then?
New Gerrit change created: https://git.eclipse.org/r/161152
Regarding the discussion in Gerrit: The UriHander stuff is not dependent on the IDE. *But* there's the preference page on which a user has to enable handling of a concrete URI scheme. This is IDE dependent. The reason for this is, that we only needed it there (at the time of development). I know that Oomph in the meantime also has link handler and needed to re-implement the enabling of that in Oomph's code. So maybe there is potential for re-use.
(In reply to Mickael Istria from comment #0) > Eclipse Help has the "internal" executeCommand(...) JavaScript function > built-in to trigger commands from inside internal Eclipse Help. However, > this doesn't work when using Help externally. > We could imagine Eclipse providing a handler for eclipse+command:// and > allowing to register it with the OS. Then, help could be switched to this > new URI form and when using Help from external web browser, the > eclipse+command:// URI will be handled by the Eclipse IDE, detected by OS, > starting or showing the Eclipse IDE and then running the command. > This eclipse+command:// URI handler could also be used to replace other > formats like links in welcome page or to simplify integration with some > JS-based UIs in RCP apps. Pls. keep in mind that only *one* application (os-wide) can handle an URI scheme. So if a user has multiple eclipse based applications this will cause issues. Also keep in mind that currently link handlers have to be enabled pro-actively by the user. So this will only work once the user has activated this on the link handlers pref page. The current JavaScript solution just works. Also see this bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=537324 When multiple eclipse instances are running clicking on a link with such a URI scheme might end up in the wrong eclipse instance (that does not have the link handler at all)
(In reply to Matthias Becker from comment #4) > Regarding the discussion in Gerrit: > The UriHander stuff is not dependent on the IDE. *But* there's the > preference page on which a user has to enable handling of a concrete URI > scheme. This is IDE dependent. The reason for this is, that we only needed > it there (at the time of development). I know that Oomph in the meantime > also has link handler and needed to re-implement the enabling of that in > Oomph's code. So maybe there is potential for re-use. So do you think the handler should be defined in the org.eclipse.ui.workbench bundl? I'd be ok with that. About the help, it's just one example of xhat such handler could enable as workflow, I don't plan changing help at the moment. Don't worry ;) Another example can be, having a GitHub "badge" with "open in Eclipse IDE" referencing the EGit clone command, or to write documentation automatically opening the right preference page for users who'd allow that is great.
(In reply to Matthias Becker from comment #5) > > Pls. keep in mind that only *one* application (os-wide) can handle an URI > scheme. So if a user has multiple eclipse based applications this will > cause issues. Great point, I totally missed that. Do we expect a user to have one and only one eclipse-based application installed? It is hardly possible to imagine.
(In reply to Alexander Fedorov from comment #7) > Great point, I totally missed that. Do we expect a user to have one and only > one eclipse-based application installed? It is hardly possible to imagine. When opening an external link (eg a magnet://) from Firefox, I get a popup that let me chose which application should handle it. There is a default one, but I'm also free to pick some other one. So I think the OS and browser seem to give the ability to select one application or another. So when bug 537324 gets fixed, users will be able to chose the application they want to run an eclipse+command:// link (not that your concerns are already try with mpc:// links). I don't think this issue of selecting between multiple RCP apps shouldn't be seen as a blocker for the user story here.
(In reply to Mickael Istria from comment #6) > > So do you think the handler should be defined in the > org.eclipse.ui.workbench bundl? I'd be ok with that. > Placing it to a bundle with name org.eclipse.e4.ui.* can make it available for more applications :) Technically for command/handler execution it is enough to have it in org.eclipse.e4.core.*: private Object executeCommand(String commandId, Map<String, Object> parameters) { EclipseContextFactory.getServiceContext(FrameworkUtil.getBundle(getClass()).getBundleContext()); ECommandService commandService = context.get(ECommandService.class); Command command = commandService.getCommand(commandId); ParameterizedCommand parametrizedCommand = ParameterizedCommand.generateCommand(command, parameters); EHandlerService eHandlerService = context.get(EHandlerService.class); return eHandlerService.executeHandler(parametrizedCommand); } Dialog-based interaction with user may require jface dependency.
(In reply to Alexander Fedorov from comment #9) > Placing it to a bundle with name org.eclipse.e4.ui.* can make it available > for more applications :) > [...] > Dialog-based interaction with user may require jface dependency. So org.eclipse.ui.workbench.swt seems to be the most relevant place. Or do you have a better one to suggest?
(In reply to Mickael Istria from comment #10) > (In reply to Alexander Fedorov from comment #9) > > Placing it to a bundle with name org.eclipse.e4.ui.* can make it available > > for more applications :) > > [...] > > Dialog-based interaction with user may require jface dependency. > > So org.eclipse.ui.workbench.swt seems to be the most relevant place. Or do > you have a better one to suggest? Yes, "org.eclipse.e4.ui.workbench.swt" looks good to me.
(In reply to Mickael Istria from comment #6) > Another example can be, having a GitHub "badge" with "open in Eclipse IDE" > referencing the EGit clone command, or to write documentation automatically > opening the right preference page for users who'd allow that is great. That would be cool.
(In reply to Mickael Istria from comment #8) > When opening an external link (eg a magnet://) from Firefox, I get a popup > that let me chose which application should handle it. There is a default > one, but I'm also free to pick some other one. > So I think the OS and browser seem to give the ability to select one > application or another. I am not sure if this is firefox or the OS in your case. Browsers seem also to have some kind of uri scheme registry... I think on Linux one can test with xdg-open from the command line.
(In reply to Alexander Fedorov from comment #11) > Yes, "org.eclipse.e4.ui.workbench.swt" looks good to me. What about an alternative to the "Link Handlers" pref page? I think this currently is IDE specific.
(In reply to Matthias Becker from comment #14) > What about an alternative to the "Link Handlers" pref page? I think this > currently is IDE specific. Why nit. However, I think it'd be better to track it in a separate ticket.
(In reply to Matthias Becker from comment #14) > (In reply to Alexander Fedorov from comment #11) > > Yes, "org.eclipse.e4.ui.workbench.swt" looks good to me. > > What about an alternative to the "Link Handlers" pref page? I think this > currently is IDE specific. Let me describe the scenario I have for Eclipse Passage Operator, that is E4 RCP without any IDE specific functionality: 1) end user launches a product and receives a dialog with functionality constraint (done) 2) end user requests a license via saving .eml file that contains an attachment with all the required data (in progress) 3) operator opens an email with license request and navigates via "eclipse+command" URL to an existing "Issue License" wizard that can be already fulfilled in this case (very nice to have) So, an alternative to configure and call link handlers for E4 RCP would be good. (In reply to Mickael Istria from comment #15) > (In reply to Matthias Becker from comment #14) > > What about an alternative to the "Link Handlers" pref page? I think this > > currently is IDE specific. > > Why nit. However, I think it'd be better to track it in a separate ticket. +1
(In reply to Alexander Fedorov from comment #9) > EclipseContextFactory.getServiceContext(FrameworkUtil.getBundle(getClass()). > getBundleContext()); > ECommandService commandService = context.get(ECommandService.class); The commandService is null here. Am I missing something, or os the BundleContext for org.eclipse.e4.ui.workbench.swt too "small" to include those services? If you prefer, I can submit a Gerrit review and we continue there.
(In reply to Mickael Istria from comment #17) > (In reply to Alexander Fedorov from comment #9) > > EclipseContextFactory.getServiceContext(FrameworkUtil.getBundle(getClass()). > > getBundleContext()); > > ECommandService commandService = context.get(ECommandService.class); > > The commandService is null here. Am I missing something, or os the > BundleContext for org.eclipse.e4.ui.workbench.swt too "small" to include > those services? > If you prefer, I can submit a Gerrit review and we continue there. Yes, please, it would be great. May be we are near a defect of e4 workbench.
Testing can be achieved opening an HTML file in the Eclipse Internal Browser, with content ``` <html> <body> <a href="eclipse+command://org.eclipse.ui.window.preferences?preferencePageId=org.eclipse.ui.browser.preferencePage">command (open browser preference page)</a> </body> </html> ``` and clicking the link.
(In reply to Mickael Istria from comment #19) > Testing can be achieved opening an HTML file in the Eclipse Internal > Browser, with content > ``` > <html> > <body> > <a > href="eclipse+command://org.eclipse.ui.window. > preferences?preferencePageId=org.eclipse.ui.browser.preferencePage">command > (open browser preference page)</a> > </body> > </html> > ``` > and clicking the link. Or just paste eclipse+command://org.eclipse.ui.window.preferences?preferencePageId=org.eclipse.ui.browser.preferencePage into the address bar of the browser
(In reply to Matthias Becker from comment #20) > Or just paste > eclipse+command://org.eclipse.ui.window.preferences?preferencePageId=org. > eclipse.ui.browser.preferencePage > > into the address bar of the browser This doesn't work for me as setting URL in the browser address bar automatically adds `http://` if the URL isn't http or https. So it ends up trying to open `http://eclipse+command//org.eclipse.ui.window.preferences?preferencePageId=org.eclipse.ui.browser.preferencePage` which results in "Error resolving “eclipse+command”: Name or service not known"
Gerrit change https://git.eclipse.org/r/161152 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=494866f839b3da696cc4855b8006e9eef8509f48
New Gerrit change created: https://git.eclipse.org/r/161275
New Gerrit change created: https://git.eclipse.org/r/161279
Gerrit change https://git.eclipse.org/r/161279 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0e0e97e1ac26fbbd34998ba4d32a1304eab7575e
Gerrit change https://git.eclipse.org/r/161275 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=5f11071488e5c4b1f5830269eab164b474d29668
Here is a demo how it looks like in actionL https://www.screencast.com/t/lVKvUaxu5fMl
