Community
Participate
Working Groups
It would be nice if GEF/draw 2d could hook into the F1 help system provided by eclipse in some way. At minimum providing help for the currently selected tool would be great but drilling down to individual edit parts/draw2d figures would be even better.
We aren't familiar with the working of the integrated help, but we plan to investigate. Any advice?
The eclipse help system (as implemented in 2.0 - havn't looked deeply into the latest build but it doesn't seemed to have changed too dramatically) registers help contexts (just string identifiers) with SWT controls through static methods on class WorkbenchHelp. I'd suggest making a Draw2dHelp which mimics this registry and override the F1 help activation in the LightweightSystem Canvas to do lookups into this registry based on the IFigure with focus. Helper methods (setHelp()?) could then be added to AbstractGraphicaEditPart that would associate a given help context id with whatever was returned from createFigure() at creation time. PaletteEntry could have similar setHelp() methods...
For the near future, we want to avoid making a "lightweight SWT" in draw2d. Are you using draw2d's focus for anything? We would probably implement a similar approach keyed off EditParts instead of figures. The help might be dependant on the model's state, which is not known to the figure.
Ok.. how about this. Add a keyHandler to the GraphicalViewer that will intercept the F1 requests, get the EditPart with focus, get its help (or the help of its parent should it not have its own), and display it using the eclipse help system. EditPart could then provided a getHelpContext() method that returns an org.eclipse.help.IContext appropriate to that part. setHelpContextProvider() could be given a object that can determine the appropriate help context from the part at hand. A simple implementation that returns the context that maps to a given string (like the rest of eclipse) could be provided, as well as one that could calculate and create a custom context based on the state of the part. Time permitting I'd like to add a help system to our product - there are some elements to our editor that would be a lot easier to understand with context-sensitive help. If this is the kind of direction you'd like to go in we could use it as well. The closer we can make it to something you'd like to see done, the less work we'll need to do to change it at a later date.
Eric to investigate and comment.
For what it's worth, I decided to do a little investigating into how feasable this all was. Three hours of "investigating" later I have it working pretty much as I described above (for our setup - I hacked around the need to change the Palette implementation). I can probably package this up and show it to you guys if you'd like.
Can you attach it to this bugzilla?
Created attachment 4763 [details] Proposed GEF addition EditPart changes for help. Doesn't include any changes to the Palette code to make it easier to associate help with a palette entry.
Thanks for the attachment, Kim. We decided that the IHelpContextProvider isn't really needed. Instead, getAdapter will be called on AbstractGraphicalEditPart, which will call the protected method getHelpContext(). Subclasses can override this and call WorkbenchHelp.getHelpSupport().getContext(id) with their own context ID. But this won't be released until after 2.1.1.
to clarify, getAdapter() will be called with IContext.class as the key. I think you are probably safer to do help differently than we will do it in 2.2. Otherwise, the method signatures might be slightly different (e.g. return type or visibility) and you could get linking problems when 2.2 is released. for compatibility, we will not register an editpartviewer by default with the help system, but we will provide your utility classes so that doing so is a one- liner :-)
Sounds good. Something to keep in mind that I came across while working on this- when you cascade up through the SWT parts (if there is no help registered in your GEF parts) it's not really 'good enough' to check to see if a given Control has a ContextID associated with it in the eclipse help system. Doing this will not catch components that have registered their own SWT HelpListener. What I did was fire HelpEvents directly at the SWT heirarchy. The problem with this is that there is no reliable way to determine if a help listener has actually been activated - I did a really hacky thing by looking to see if the focus had changed after firing the event, assuming that any help listener would interact with the UI in some way. If the focus hadn't changed I fired an event at it's parent, and so on... there really doesnt seem to be a good solution to this problem...
2.2
LATER and REMIND resolutions will be going away with the upgrade of Bugzilla to the latest Bugzilla 3.4. They are no longer part of the default Bugzilla installation. See http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00778.html for the announcement. As a result RESOLVED + REMIND OR LATER will be changed to RESOLVED + WONTFIX This unfortunately also means I need to REOPEN and then RESOLVE as WONTFIX Sorry for the inconvenience.
