Community
Participate
Working Groups
Currently you have to use a wizard (WIZARD_BASED_USER_INTERFACE) to show any context sensitive help in a refactoring dialog. This is cumbersome particularly when your refactoring dialog is quite large already and you don't want to add the title area. Also since many refactoring dialogs are quite complex, adding the title area tends to clutter the UI and make it harder on users. On a cursory glance, RefactoringWizardDialog2 would just need extend TrayDialog.
Created attachment 188709 [details] Proposed fix The lightweight style has been added to remove as much noise as possible from dialogs. Always adding a help button would counter that effort. But we can make this configurable: With the attached patch, you just have to add the SHOW_HELP_BUTTON flag in your call to the constructor of RefactoringWizard. Would that suit your needs?
That would certainly work but couldn't it be (Instead of) setHelpAvailable(wizard.internalShowHelpButton(InternalAPI.INSTANCE)); (could be) setHelpAvailable(wizard.isHelpAvailable());
Created attachment 188772 [details] Proposed fix 2 I don't see why access to RefactoringWizard#fFlags needs to be hidden at all. Rather than adding an extra method for the new flag, I'll just add a getter for the field. I didn't choose getFlags() as method name because RefactoringWizard is to be extended by clients and I want to avoid accidental name clashes.
I'm a bit confused (not uncommon ;) Why not reuse the existing isHelpAvailable method on the wizard class? I believe its intended purpose is exactly the same. So instead of creating a new flag, getFlags(), etc just call the existing isHelpAvailable(). If I'm creating a new refactoring wizard I just need to make sure to setHelpAvailable(true) in the constructor. I think thats true today if I used WIZARD_BASED_USER_INTERFACE. -Chris
Looks like I was also a bit confused, since I didn't even see that RefactoringWizard already inherits an isHelpAvailable() method ;-) Unfortunately, the WizardDialog implements two kinds of help: A) A legacy "Help" button that shows up in the button bar with a text label. This one is controlled by Wizard#set/isHelpAvailable(). For this button to work, each IDialogPage has to implement a performHelp() method. This style is rarely used nowadays. B) The TrayDialog-style "?" button at the very left of the dialog. This one is controlled by TrayDialog#set/isHelpAvailable(). This button just invokes the standard Eclipse help (via the SWT.Help event). Since we don't want the old text button in the lightweight refactoring dialog, (B) is the preferred solution. We could theoretically abuse the helpAvailable bit from the RefactoringWizard to toggle the button, but I think that would be even more confusing.
I agree we don't want the "Help" button. Its sort of cludgy the way it is right now in with the Wizard/TrayDialog both having is/setHelpAvailable and it does different things. Without knowing better, I would assume Wizard#set/isHelpAvailable would also control the "?". I'm of the opinion to abuse RefactoringWizard#is/setHelpAvailable for the "?" on the DIALOG_BASED_USER_INTERFACE. IMO its quicker, doesn't add any new API, and probably adheres better to a user's expectation. But the existing legacy handling of Wizard#is/setHelpAvailable does make the whole thing cluttered. I'm definitely not going to complain either way - if we get the help working at all I'll be happy :)
Created attachment 190570 [details] Fix 3 I don't want to add even more confusion by changing the meaning of the outdated Wizard#setHelpAvailable(boolean) to something different depending on the RefactoringWizard style. To ease the pain, I've deprecated RefactoringWizard#setHelpAvailable(boolean) and we'll go with a new flag RefactoringWizard.SHOW_HELP_CONTROL.
Fixed in HEAD.
