Community
Participate
Working Groups
Dialogs that remember their bounds always do so when the dialog closes. It would be nice if they only remembered their bounds when the user actually resized them. Otherwise they will record bounds that include dynamic content changes such as the help tray, details buttons, or any other composites that open as a result of working with the dialog.
spawned from bug #162124
We need a term for "the help tray, details buttons, or any other composites that open as a result of working with the dialog". I suggest "expander". There are always going to be cases in which a dialog will open with a different set of expanders open than last time. Even if the dialog remembers which expanders were open last time, it might not be able to reopen some of them because they might be disabled based on changes to the data in the dialog. (For example, the user had a "Details >>" area open last time, but this time the data in the dialog doesn't have any details.) Let the "base size" of a dialog be its size excluding any expanders. I propose remembering the base size of a dialog and reopening it at a total size such that its base size is the same as last time. Individual expander-containing dialogs are already doing this sort of calculation when expanders are opened or closed; the calculation could simply be factored out into a separate method that could also be called by the size-persisting code in Dialog. If this were done, the size-persisting code would always open the dialog to the same total size that it would have adopted last time if the user had manually opened/closed the appropriate individual expanders, which is a desirable property.
Interesting idea. Rather than introduce notions of bases and expanders in the framework, the simplest fix would be to make the saveDialogBounds(Shell) method protected. Then subclasses that introduce expanders could override this behavior (as well as getInitialSize()) to store and interpret the saved settings as necessary. I'm just not sure yet that we want to open this behavior up given no one complained about this problem (apart from me while fixing bug 162124). Thoughts?
(In reply to comment #3) > Rather than introduce notions of bases and expanders in the > framework, the simplest fix would be to make the saveDialogBounds(Shell) method > protected. Then subclasses that introduce expanders could override this > behavior (as well as getInitialSize()) to store and interpret the saved > settings as necessary. I think this is a better way to achieve the same effect as my idea. However, the Dialog implementations contain several behaviors that subclasses will want, such as saving the *location* in saveDialogBounds, checking whether the font has changed, and storing DIALOG_DEFAULT_BOUNDS if the user has never resized the dialog. Subclasses need a way to reuse those behaviors while inserting their own size-adjusting logic, and they cannot easily do so by calling the entire Dialog versions with super.getInitialSize() or super.saveDialogBounds(shell).
Agreed, the saveDialogBounds would break up its behavior and introduce a protected method for calculating bounds. Not sure yet about getInitialSize() (ie...it may be good enough to override completely). At any rate, I don't see this as critical for 3.3. We need PMC approval for any API additions at this point. Since this came up as a theoretical discussion vs. user complaint, I don't have an argument for adding the API at this stage. I am removing the 3.3 milestone. Also changing the title to reflect the evolving discussion. I noticed that you voted for this bug. If you want to make an argument that it is critical for 3.3, please say so...
I agree that fixing this bug is not critical for 3.3.
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
