Community
Participate
Working Groups
I'm not sure what the plan is for IHelpService but if we want to use it as e4 replacement of the help system we should allow to register help to it. I suggest to add a method setHelp(Object, ID) to the interface. In our default implementation we use the type to call the corresponding method on IWorkbenchHelpSystem.
Paul, Wojciech, please advise if that is correct path to go forward.
I don't recall any concrete designs or plans to implement E4 Help Service. I added the IHelpService because it was necessary to fix bug 380946. Currently it is not a part of API (it is in an internal package) but I agree that sooner or later we should add help service to E4 API. The current help system (IWorkbenchHelpSystem) is tightly coupled to SWT. Would you like to pass to the setHelp(*, ID) instances of Object or more specific interface (e.g. MUIElement)? BTW. I think that as a part of API it should be called *E*HelpService.
(In reply to Wojciech Sudol from comment #2) > The current help system (IWorkbenchHelpSystem) is tightly coupled to SWT. > Would you like to pass to the setHelp(*, ID) instances of Object or more > specific interface (e.g. MUIElement)? At the moment I would pass instance of object which in the default implementation could be cased to SWT controls or other elements like IAction. Other, non SWT based implementation could cased to other required types. > BTW. I think that as a part of API it should be called *E*HelpService. I agree, I open a new bug for the rename.
(In reply to Lars Vogel from comment #3) > I agree, I open a new bug for the rename. Bug 445723.
Before getting too far down the path with this, I think a help subsystem that's API needs to be designed. If it's not going to be just a passthrough for the Workbench help, what does it need to do? Is it going to be a downport of the User Assistance framework? Is it going to support the embedded help view and the Help Contents window? Cheat sheets? Is it going to be something simpler based on jetty? PW
(In reply to Paul Webster from comment #5) > Before getting too far down the path with this, I think a help subsystem > that's API needs to be designed. Currently the IHelpService / EHelpService is internal. I think adding a method to it to make it work is a first step to see what would be a good first step to define an API. > If it's not going to be just a passthrough for the Workbench help, what does > it need to do? Is it going to be a downport of the User Assistance > framework? Is it going to support the embedded help view and the Help > Contents window? Cheat sheets? > > Is it going to be something simpler based on jetty? I think the current platform implementation should be a passthrough for the Workbench help. I don't think we currently have the resources to redesign the whole help story.
(In reply to Lars Vogel from comment #6) > > I think the current platform implementation should be a passthrough for the > Workbench help. I don't think we currently have the resources to redesign > the whole help story. Then it doesn't really matter what you call it since it shouldn't become API. PW
(In reply to Paul Webster from comment #7) > Then it doesn't really matter what you call it since it shouldn't become API. AFAIK our strategy is to first design something useful, than use it internally and if it works we make it API. I think in this case API can be independently discussed from the redesign of the help system.
One place where we could use the EHelpService is in the ShowViewDialog from Bug 430988.
https://git.eclipse.org/r/#/c/35469
https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=214837fda6c68c64276065d22f7a74e8a94b64ae
I use this in new method in platform.ui via Bug 457434.
