Community
Participate
Working Groups
MacOS 10.4.2 and earlier OS X versions, in Eclipse 3.0, 3.0.1 and 3.1. I do not know if this bug appears on other platforms, I'd guess it does. Consider the Rename Field preview dialog used for refactoring. This dialog would always benefit from having as much screen space as possible. Yet even though this dialog has a working resize icon on the lower right, it does not have a green maximize "gumdrop" (maximize button or whatever it's called) in the upper left (on the title bar). Eclipse's use of the maximize button seems haphazard: some resizable dialogs have one, some don't. Unfortunately many resizable dialogs that should have it, like any of the refactoring previews, do not. Not only would this be useful in terms for following good human interaction guidelines for UIs (i.e. it makes Eclipse easier to use), note that having the green resize gumdrop would be a quick fix for whenever the Rename Field preview dialog was misplaced - see bug #102907.
As far as I can remember the reason for not having the max/min buttons is that UI guidelines say that these buttons are unwanted on dialogs. Can someone from the Platform/UI team please comment on this.
The Preferences dialog is a modal dialog with a maximize button, which comes in really handy since that dialog has a lot of content. I'd suggest that the refactoring preview dialogs should be included under the same guidelines as the Preferences dialog!
I'm of the opinion that if it's a dialog with a lot of content and could benefit from a maximize button, one should be added. Especially given there are open bugs with respect to its placement. But I'm fairly new to the Platform/UI team and may not be aware of any other history/discussion on this topic. Nick -do you have an opinion on this?
I'm not aware of any guidelines arguing against the max button, particularly if the dialog already has a title bar and close box. It's currently up to each dialog to set the appropriate style bits, but it would be good to have some consistency here, with support in JFace for doing the right thing. E.g. add Dialog.isResizable(), with default false for backward compatibility. If true, then its shell would be created with the right style bits to make it resizable and with a maximize button.
I agree as well - you would only leave them off if you couldn't resize the dialog.
Now that it's 3.3 planning time I'd like to reiterate my request for for this enhancement. It would certainly be in keeping with the 3.2 project's "Rich Client Platform" theme of SWT having "native platform integration". Now that some dialogs can display help "in situ", adding even more content to the dialog, this will become even more important.
consider for 3.3 As with the support for remembering dialog size/position, the first step would be adding the framework methods and then individual dialog implementations would have to override. One possibility for quicker adoption, although it would automatically affect existing dialogs: Do as Nick suggests in comment #4, but implement isResizable() to check existing style bit settings, and return true if the RESIZE style bit has already been set. This would allow existing resizable dialogs to get min/max buttons for free, and new dialogs could implement the isResizable() method to return true to get it all for free.
Another dialog that could do with a maximise button - The "Find and install updates" wizard, particularly the "Updates" page.
This would require API change at this point. We didn't get to it soon enough. Marking with usability and api keywords so it will have more visibility.
Fixed in HEAD >20070702. Note that the fix is to provide the framework methods that allow dialogs to specify that they are resizable (Dialog.isResizable()). When true, we set both the RESIZE and MAX bit. As suggested by Nick in comment #4, the default is false for backward compatibility. I did not take my own suggestion in comment #7 because it would mean overriding the shell creation sequence in order to check the style bits at the last possible minute for dialog creation. I thought it cleaner and more straightforward to simply change the default bits used in the Dialog constructor. All this means that any particular dialog that has RESIZE and no MAX button is likely setting their own shell style, and the dialog won't be fixed until the dialog overrides isResizable(). As a side note, per bug #97229, SelectionDialog returns true for this method, so a lot more dialogs will be automatically resizable now.
Susan, have you considered adding some helper methods to make saving/restoring the dialog's state (size, max'd/min'd...) easier? In the Workbench we'd like to have every dialog re-open in the same state that it was last closed in, including across sessions... Something as simple as a 'String getState()' and a constructor that can take a string in the 'getState' format would do it (note that the format of the string need not be public to allow for non-breaking changes in the future).
Eric, please annotate bug #113282 with any particular issues. We have protocol for remembering size and position in the dialog framework, but not everyone has adopted it yet...
verified on WinXP, I20070807-0010
