Community
Participate
Working Groups
I20051116-1332 Bug 33550 introduced a mechanism to restore the position and size of dialogs. We should have a story for restoring the default size for such dialogs. Usually, dialogs come up with an apropriate size and don't need to be resized. E.g. the Search dialog is initially as compact as possible. After having resized the dialog, I don't see a possibility to get the original size back now. IIRC, Mac applications usually do this when the user clicks on the green (+) button, but I'm not aware of a "standard" paradigm on Windows. A solution that would not require an additional widget in/around each dialog could be a global "reset" facility that would just delete all stored preferences.
investigate during M5, in case it affects API
I agree with Markus that it would be nice not to have to add an additional control to each dialog to make it return to its originally computed bounds. Yet I really prefer the idea of a gesture whereby the dialog can be restored to its default size without having to go slam a preference somewhere, and without having to add a new control. When you want the dialog to return to its size, you just want it to work, not to close it and go fix a preference. I don't see a platform independent mechanism for doing this, but perhaps we could define a gesture that can be used in our dialog framework. One idea: restore the dialog to its computed size if the user double clicks in the button bar area, but not in any of the buttons themselves. I realize this is obscure, but it's kind of like double-clicking on a title bar to maximize and restore...once you know how it works, it's really handy. If you do this by accident, it could be surprising, but there'd only be a change if the dialog had been resized. Too obscure? Other ideas?
Doubleclicking in the button bar is a bit obscure, but I don't have a better idea either. It's surely convenient and Windows users might already know something like that: doubleclicking in the gray area around the Task Manager window switches the window titlebar and menus on and off. I would go for this solution. It can always be made more visible later if need arises, but having it somewhat hidden is always better than not having a chance to restore at all. The best solution would be an additional button in the dialog shell's title bar next to the min and max buttons, but I don't think SWT can provide this (at least not for 3.2).
I've implemented and released a solution, although there are some caveats. I still believe it's a "better than nothing" solution. Dialogs will restore to their initially computed size whenever the user double clicks in the button bar, or its parent, or its parent...all the way up to the contents. In simple dialogs this is the button bar and contents composite, but in more complex dialogs there may be nested composites in between. One nice thing about the feature is that it's useful in dialogs even when the dialog doesn't store its size between invocations. That is, if you resize a dialog, leave it open, and want to restore its size, double clicking in the button area will work, even if it doesn't save its bounds in the dialog settings. The caveat is that some deep dialog hierarchies (such as SelectionStatusDialog) insert a control such as a status area next to the button bar, and when this control is empty, it is puzzling that double clicking there doesn't restore the dialog size. You typically have to click below the buttons in order to get the behavior. One general way to describe the behavior is that you need to click near the bottom left corner of the dialog to be sure to restore its size, although some dialogs are more permissive, letting you click anywhere in the button bar area. I didn't add protected protocol to allow dialogs to specify which controls should hook double click because we may design a control or other affordance later, so I don't want to introduce framework methods for the current implementation. Closing this for now. If there are many complaints or we decide it's too obscure to bother with, we can always take this out, but I think it's nice to have it there when needed.
verified behavior in 20060214-0800 on Win XP. side note: now that there is a help button present in the lower left corner, I wonder if there could also be a graphic button indicating "restore dialog size."
I do not favor yet another button. It is a nice-to-have feature but not of the same importance than help. A better "visual" would be a context-menu.
After fixing bug 111653 I tried it on the template edit dialog and the only spot that allowed me to restore the size was the small rectangle right to the 'Cancel' button.
> I do not favor yet another button. > [..] > A better "visual" would be a context-menu. I agree, a context menu would be nice. Filed bug 137315 for the tiny responsive area in latest builds.
Reopening this bug, see also bug #140306.
The double-click approach has been unpopular due to bugs (such as triggering on the help button, disabled buttons) and also due to its obscureness. Users have reported the behavior as a bug rather than considering it a feature. The open bugs have now been fixed. We're looking for feedback on whether the feature is now acceptable or whether we should still be looking for an alternative gesture for restoring a dialog to its preferred size.
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=140306#c56 Dani votes for pulling the behavior.
I also don't think that adjustments to the area of doubleclick-sensitivity will ever yield a satisfying solution for this problem. We need an affordance for the functionality -- everything else is a hack and too hard to discover. How about this: - Each dialog that wants to remember size and position should offer a "view menu" (that downwards-pointing triangle we have in the upper-right corner of the Quick Outline, the Open Type dialog, the views, etc.) - The view menu offers a "Restore Default Size" item. This could also be combined with the "Remember Size and Location" toggle, i.e. the default could be restored when the item gets unchecked. - Dialogs that don't have a view menu should not remember size and position. The second best solution would be the context menu (see bug 140306 comment 43).
I am very hesitant to add any form of menu because I don't know what else we'll be tempted to put in there. Plus either all dialogs get it for free (which may not fit their design) or we'll have inconsistencies. Seems we need some specific affordance similar to min/max buttons but I think that route justifiable scares us. While I have a slight preference to remove the feature (for reasons noted previously and for those Dani mentioned), its not the worst offense we have in the workbench. Thus I could believe that if some segment loved it, we'd say the net is its worth keeping. I'd be interested therefore to hear argues *for* keeping it.
Okay, no one is arguing for it. Numerous bug reports against it, thinking it's a bug. The original feature request was by Markus, who finds the results at this point as unsatisfying as everyone else. Yet we can't agree on an alternative. So at this point I will yank the feature (tracked by bug #175545) and keep this bug open as a request to provide some way to invoke the behavior. I'm removing the M6 milestone. (The double-click will be yanked in M6, but no alternative will be provided until we find a satisfying solution).
Created attachment 59829 [details] patch replacing double click with context menu Markus' original patch to #140306 which uses a context menu. Moved to this bug so we don't lose it.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
