Bug 330595

Comment 1 Joachim Mairböck 2011-06-07 06:04:05 EDT

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

Comment 2 Marco Descher 2012-05-09 03:52:19 EDT

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?

Comment 3 Paul Webster 2012-05-09 07:28:48 EDT

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

Comment 4 Lars Vogel 2012-05-09 08:11:06 EDT

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.

Comment 5 Marco Descher 2012-05-09 08:15:18 EDT

Created attachment 215321 [details]
Integrating documentation and context help

Comment 6 Marco Descher 2012-05-09 08:15:40 EDT

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.

Comment 7 Lars Vogel 2012-05-09 08:20:20 EDT

A simple approach would be to have a listener attached to the control which opens a sub URL.

Comment 8 Marco Descher 2012-05-09 09:37:48 EDT

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!

Comment 9 Lars Vogel 2015-01-22 13:53:28 EST

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

Comment 10 Lars Vogel 2015-01-27 05:58:46 EST

.

Comment 11 Ralf Heydenreich 2015-04-30 01:53:43 EDT

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.