Bug 127852

Comment 1 Ed Burnette 2006-02-20 11:36:42 EST

+1 to this. Press it once, and the tray slides out, press it again and the tray should slide back in. Mac dialogs have a nice affordance for this that should be used if possible, but even on Windows that's the first thing I tried. This should take the place of the little white 'help close' button in the upper left.

Comment 2 Dani Megert 2010-11-25 03:33:12 EST

This is in the TrayDialog.

Comment 3 Prakash Rangaraj 2010-11-25 03:50:16 EST

Is there a possibility that a WizardPage could associate help pages for individual controls in that page and clicking Help would change the help page of the control in focus?

Comment 4 Markus Keller 2010-11-25 06:15:26 EST

(In reply to comment #3)
That should already work with a normal call to
    PlatformUI.getWorkbench().getHelpSystem().setHelp(..)

Please file a separate bug with concrete steps if it doesn't work for you.

Comment 5 Prakash Rangaraj 2010-11-25 07:51:51 EST

(In reply to comment #4)
> (In reply to comment #3)
> That should already work with a normal call to
>     PlatformUI.getWorkbench().getHelpSystem().setHelp(..)

    Then this enables the user to change the focus to a different control and click the button to get help that is specific to that control. If we make the button to toggle, that behaviour is lost.

Comment 6 Dani Megert 2010-11-25 08:06:10 EST

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > That should already work with a normal call to
> >     PlatformUI.getWorkbench().getHelpSystem().setHelp(..)
> 
>     Then this enables the user to change the focus to a different control and
> click the button to get help that is specific to that control. If we make the
> button to toggle, that behaviour is lost.

Not sure I understood what you want to say, but what would definitely be broken is the option to reset the help by clicking the (?) button (in case some links got clicked).

Comment 7 Markus Keller 2010-11-25 08:10:53 EST

(In reply to comment #5)
>     Then this enables the user to change the focus to a different control and
> click the button to get help that is specific to that control. If we make the
> button to toggle, that behaviour is lost.

I see, but that workflow is already not great today: Who wants to give focus to each UI element and then move the mouse to the help button and click again, only to discover that most elements don't have a specific help context?

This fine-grained help is used rarely, and I don't think people even realize it's sometimes available (an example I found via code search is the CVS "Configure Tags" dialog). If we really wanted to promote fine-grained contexts, then we should rather make the help tray track focus actively, so that the user doesn't have to poll. And F1 or double-click will still be available to poll.

Comment 8 Dani Megert 2010-11-25 08:13:36 EST

>And F1 or double-click will still be available to poll.
True.

Comment 9 Markus Keller 2010-12-14 06:11:56 EST

Created attachment 185121 [details]
Fix

Turns the help button into a toggle. Leaves the existing close box in the tray, since people are used to that by now.

Comment 10 Markus Keller 2010-12-14 06:14:31 EST

I'll release this for the next I-build unless someone speaks up against it.

Comment 11 Dani Megert 2010-12-16 07:31:49 EST

(In reply to comment #10)
> I'll release this for the next I-build unless someone speaks up against it.

Something seems to be fishy with the patch:
1. Ctrl+Shift+T
2. Click the 'Help' button
   ==> good: help shows as "About Open Type" and 'More results:' section is here
3. Click the 'Help' button to close the help
4. Click the 'Help' button
   ==> bad: help shows as "About" and 'More results:' section is missing

Comment 12 Markus Keller 2010-12-16 10:41:01 EST

Created attachment 185330 [details]
Fix 2

(In reply to comment #11)
Thanks, good catch! That scenario reveals a few old flaws:

- TrayDialog#closeTray() doesn't care about the focus, so after calling that method, the focus falls back to the dialog's shell. org.eclipse.help.ui.internal.views.HelpTray implements a workaround for that in the close button (calls "shell.setFocus();")

- org.eclipse.help.ui.internal.views.ContextHelpPart#updateTitle(Control) calls #computeSearchTerms(Control), which always starts looking for a title in the the parent of the passed control. When the dialog shell has focus, the code misses the obvious target.

The TrayDialog should try to restore the focus when the tray is closed. The attached Fix 2 implements this. I'll file a follow-up bug for Help to remove their setFocus() and fix their computeSearchTerms(..).

Comment 13 Markus Keller 2010-12-16 11:01:47 EST

Committed Fix 2 to HEAD.

Comment 14 Dani Megert 2011-01-25 03:29:53 EST

Verified in I20110124-1800.

Comment 15 Rajesh 2011-01-25 05:11:28 EST

Verified for 3.7 M5 with I20110124-1800.

Comment 16 Chris Goldthorpe 2011-03-08 13:26:35 EST

There is a regression as a result of this fix, see Bug 339267 - TrayDialog closes the tray if the help button is pressed with a cheat sheet open