Bugzilla – Full Text Bug Listing
| Summary: | [Dialogs] - Platform dialogs that should remember size/position | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Susan McCourt <susan> |
| Component: | UI | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P5 | CC: | jay_schmidgall, jcompagner, robert.monteleone, sean_montgomery, sxenos |
| Version: | 3.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Susan McCourt
cc'ing Stefan. As you use the new stuff and see dialogs that aren't remembering location and size, annotate this bug with the ones that annoy you. I posted the entry, below, in the Eclipse Platform Newsgroup, and thought that it might be approprate here. In summary, I am looking to persist the size and location for a ContainerSelectionDialog. Since I wrote the note, I see a similar issue for a NewFolderDialog. Newsgroup entry: I am working on upgrading CDT UI support to persist the size and location of simple dialog boxes, as described in bugzilla #33550. I have successfully used the new mechanism described in the bugzilla entry, but have a specific question in a particular dialog instance. In CDT we use the "ContainerSelectionDialog" in some instancee. I am not able to apply the paradigm described in bugzilla #33550 to persist the size and location for these particular dialog boxes. The problem is that 1) the support, via impelmentation of the getDialogBoundsSettings() etc. method is not present in the class and 2) according to the documentation, the class is not supposed to be subclassed, which prevents me from adding the method in a subclass. As such, I am not able to persist the size and location of these dialog boxes in CDT. How can I proceed here? Is there another approach? Or, is it the intention that such dialog boxes not be allowed to have their size and location persisted? Note that I am using Eclipse 3.1 M4 currently. Bob, sorry for taking so long to respond...this fell through the cracks. In M6, you can use setter methods to set up the dialog settings and strategy. This was added in M5 in SelectionDialog. *** Bug 146277 has been marked as a duplicate of this bug. *** One suggestion from bug #146277 is that in cases where we chose not to remember size due to multiple pages (such as the preferences dialog), we remember whether it was maximized and restore the maximized state if it was... From bug #161465 - Dialogs that incorrectly appear on the primary monitor (again, probably not a complete list): Project>Clean (1) Window>New Window Open Type (Ctrl-Shift-T in Java perspective) (1) These could be fixed by using the standard support *** Bug 161465 has been marked as a duplicate of this bug. *** From bug #162376 - Most dialogs don't remember their size >for example the preference dialog or the properties dialog of a project. All >dialogs that are shown in eclipse should remember there exact view state. So >not only the size and location but also try to save the internal state >(splitpane/divider locations) note that we specifically don't store the preferences dialog size (only its location) so that it comes up at a reasonable default size rather than the size of the largest page visited on the previous invocation. We may want to revisit this... *** Bug 162376 has been marked as a duplicate of this bug. *** yes please revisit this. I have a large screen resolution on my laptop 1920x1200 so i size all the dialogs much bigger because i get then a much better default overview for my installation. I think the best size is the size i set myself. Not a default size eclipse thinks it wants (thats only fine the first time) Closing this bug. The remember size/position API has been around for several releases now and we should just be opening separate bug reports against the specific components for any dialogs that could benefit from using or changing their use of this support. |