Community
Participate
Working Groups
What's the plan for UA integartion in e4, similarly to IWorkbenchHelpSystem? At the very least, parts are expected to do something like: PlatformUI.getWorkbench().getHelpSystem().setHelp(partsControl, "my.view.id");
According to the Wiki [1], accessing the Help System would mean just injecting it. I would like to use it in a handler to open the help like this: @Execute public void execute(IWorkbenchHelpSystem helpSystem) { helpSystem.displayHelp(); } But the handler is not called because there is no IWorkbenchHelpSystem in the context. If I would annotate the parameter with @Optional, helpSystem would be null. [1]: http://wiki.eclipse.org/Eclipse4/RCP/FAQ#Associating_help_context_with_a_control
Aren't there many more aspects to this? E.g. in 3.x I could add a helpContextId to both commands and handlers, such that the respective context help entry was opened when calling the dynamic help. I don't see how to realize this in the e4 Application model. If I use the 3.x help system, is there no way to declaratively provide the helpContextId of a command? How do I do this in e4?
In 4.3 more aspects of the 4.2 Workbench services (that supports the 3.x API) will be made available to Eclipse 4 RCP apps. But with 4.2, you can only access this functionality if you are running a 3.x RCP app (and the Workbench). PW
I personally think the port of the help system is not important for Eclipse RCP application. I think a webpage and a SWT browser widget is the better solution.
Created attachment 215321 [details] Integrating documentation and context help
But how would you then associated what webpage to call, when performing a dynamic help request on a specific control? I've been struggling some time to find a concept on how to integrate both dynamic help and traditional documentation, if you're interested please find the enclosed image. Together with the idea of single sourcing this would cover the entire documentation needs; both context dependent and as dedicated documentation.
A simple approach would be to have a listener attached to the control which opens a sub URL.
Alright, thanks for your advice! I thought about it, and it really seems better, as I can create an own handler, to get the active part and by this resolve the correct site. One problem yet exists: If I want to have context help for a command contribution element (e.g. Button) while it is active: 1. I can't figure out how to keybind to elements not part of a view resp. where the Button is located in the views toolbar (that is where BindingContext is not applicable) 2. How to get the ID of the command to be executed by the resp. command contribution control? As I need this to provide the resp. correct context help site? So e.g.: _____________ | |_G_| | View A | |____________| If View A is selected and I have a keybinding to M1+F I can execute a handler to call the context help for this view. If I however want the context help for Button (G) by setting it active; then first there is problem 1 (as above) and additionally problem 2 (that is if I can call the keybinding, how do I get the ID of the command handled by G)? Thx!
We have now the provitional EHelpService which delegates to the IWorkbenchHelpSystem in the Eclipse IDE. Marking as fixed, the customer can now either reuse IWHS or implement his customer help story. Related fix. https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=214837fda6c68c64276065d22f7a74e8a94b64ae
.
The WorkbenchHelpSystem depends on org.eclipse.ui and needs the compatibility layer. I think this solution is only a workaround because it's no "real" E4 architecture.
