Community
Participate
Working Groups
There are several dialogs that remember its size and position. Since restore the size and considering screen size and font changes isn't trivial JFace's Dialog class should support remembering and restoring size and position. These would realy ease the task for subclasses. May be you can steel the code from OpenTypeSelectionDialog.
Consider for 2.2.
Not for 3.0, unfortunately. We would need extra information such as a key to use for storing the coordinates. JFace has many reusable/subclassable dialogs and you wouldn't want the same size to be remembered for the different uses of the same class. Would also want to remember different positions for different parent windows. Also needs to be aware of multiple monitors.
I looked at this specifically for bug #105665 (Open Resource dialog) which was fixed for 3.2 M1. For Open Resource, I implemented the behavior in the ResourceListSelectionDialog superclass, based roughly on the Open Type and Clean dialogs. Most of the bugs I've seen on this topic say that Open Type is working as expected, including a dual monitor user who reported bug #105665. So I think it's mainly a matter of storing the dialog settings. The dialogs cross multiple plug-ins, so they would need to supply their settings instance and section name. For a general solution, we could define new protected methods in JFace Dialog that answer the settings instance and settings section name, and the coordinates could be stored there. The default implementation would be null, which means the size and location settings would not be stored. The settings and section name methods would generally be defined in concrete subclasses or else you end up sharing the values across dialogs, which may or may not be appropriate depending on the hierarchy. This seems quite reasonable, and dialogs that did not implement the new methods would continue working as before, with no memory of their previous location. I could look at this for M2. Nick - what do you think?
Susan, I support this. When fixing it we should have a story for multi monitor setups as well. One idea would be to always store the position of "parented" dialogs relative to the workbench window.
Dirk and/or Nick - can you point me to any doc (or explain here) what a multi- monitor setup looks like from an API point of view? Do I have multiple SWT displays or does SWT return a surface area that is the total size of the monitors? I want to make sure I understand the issues here.
I found some relevant bugs explaining Dirk's comment #4. Remembering the previous size/location is a good thing and is requested in many bugs. In a static setup, this solves most of the issues, because the user can fix the size/position if it is wrong the first time, and then everything is fine. The problems arise when the workbench is moved to another monitor (bug #99078), or when the monitor setup changes (bug #64886). By remembering the location relative to the parent shell (and correcting for out of bounds issues), I think we can solve most of these problems. I will investigate this during M3.
*** Bug 108801 has been marked as a duplicate of this bug. ***
The proposal sounds good. Please talk to Stefan if you need help with multi-monitor logic. He's quite passionate about this issue, and knows the APIs well.
Whether the coordinates are stored relative to the parent or to the display, what coordinate system is used to determine and correct out of bounds conditions? The monitor's coordinates or the global display coordinates? The current SWT Monitor for a control can be obtained. The computation of the current monitor is platform-specific and as I understand it will return the monitor that the parent window is "mostly" on according to the rules of the underlying platform. Given we can obtain the appropriate monitor for a dialog's parent window, should we use these coordinates to constrain the dialog? Doing so will ensure that the dialog appears on the correct monitor for its parent window, but that it won't cross monitor boundaries, even if the parent window does. This will help in the cases discussed above (monitor setup changes, workbench window changes monitors), but would prevent the user from repositioning a dialog to always open on a different monitor. The logic may also differ based on the kind of dialog. Constraining a dialog to the current monitor is likely what you want for hovers and small popup dialogs, but may or may not be appropriate for other dialogs. Thoughts?
See http://msdn.microsoft.com/library/default.asp?url=/library/en- us/gdi/devcons_4esj.asp for a description of monitors in Windows. The SWT model is the same.
Perhaps some more detail will help. I have two monitors with the main window positioned across both monitors. My secondary monitor is to the right of my primary monitor. The dialogs that always appear on the secondary monitor are always positioned on the left edge of the monitor. I'd like to see all dialogs behave the same as the Find/Replace which remembers its last position. Why wouldn't that work?
Remembering the last position/size is definitely the right thing to do. At this point I'm just working on what to do when the last position/size does not fit on the monitor or display (virtual monitor area). If the last position is remembered relative to the SWT display (virtual display area), dialogs can cross monitor boundaries, which may or may not be okay. Previous bugs have explained this is not okay for hover popups such as content assist, etc. Regardless of whether the dialog crosses monitor boundaries, unexpected positioning can occur when the workbench is moved to another monitor (bug #99078), or when the monitor setup changes (bug #64886). If we remember the dialog position relative to the parent window, and the parent window is moved, we can still get out of bounds conditions. In these cases we want to constrain the dialog somehow. So the question is... - if the remembered size/location means that the dialog will cross monitor boundaries, is that always okay? sometimes okay (based on the type of dialog)? never okay? - if the remembered size/location no longer fits (due to setup change, movement of parent window), should we constrain to the display or to the parent window's monitor?
Newly opened dialogs should never cross monitor boundaries, since text that crosses the monitor boundary is unreadable on most dual-monitor systems. See Window.getConstrainedShellBounds for the correct logic. The dialog size needs to be constrained to the Monitor's client area (which takes into account the region occupied by the Windows start bar), not the Monitor or display bounds. One possible exception: if the dialog crossed a monitor boundary when its position was last saved, it's possible that the user actually wanted it there and that crossing a monitor boundary could be permitted... but my hunch is that this case is rare and that most multimonitor users would be happy if their dialogs never crossed a monitor boundary. I believe that storing dialogs with coordinates relative to the parent shell (as suggested in comment 3) and then preventing monitor overlap using Window.getConstrainedShellBounds would be the correct solution.
The Find/Replace dialog does just that, so the solution is already implemented somewhere. You just need to get all the other dialogs to follow suit.
Here's the most common use-cases: 1. Single-monitor user, maximized Eclipse. Expects dialogs to reappear exactly where they left them. Display-relative and parent-relative coordinates are equivalent. Dialogs should never extend beyond the monitor's client area. 2. Single-monitor user, windowed Eclipse. It is likely that some users would expect dialogs to reappear in the same absolute position, other users would expect dialogs to reappear in the same position relative to the parent, and that all users could tolerate either behavior. Dialogs should never extend beyond the monitor's client area. 3. Multi-monitor user, multiple Eclipse windows, no Eclipse window spans a monitor boundary. The most common configuration is probably one maximized Eclipse window per monitor. Expects dialogs to always open on the same monitor as the parent, and to never extend beyond the client area of a single monitor. 4. Multi-monitor user, one Eclipse window that spans all monitors. Expects dialogs to reappear exactly where they leave them. It is unlikely that these users will notice the difference between parent-relative and display-relative coordinates since the coordinates of the parent window will rarely change. Some of these users will have low-profile LCD monitors and will be able to tolerate dialogs that span multiple monitors. The remaining users would prefer to have dialogs open fully within the client area of a monitor. 5. Virtual desktop user (linux, mostly). One monitor, one or more Eclipse windows and the usable Display area exceeds the visible area. They can view a small portion of the display at a time by scrolling their screen. Will not want to scroll the screen to locate dialogs. Although I only know of one user who works this way, I suspect that all of these users would expect dialogs to reopen with parent-relative coordinates since this would tend to place them near the parent window and result in less scrolling. I believe that in all cases, the user would be satisfied with dialogs that save parent-relative coordinates, and that never span the client area of a monitor.
>The Find/Replace dialog does just that, so the solution is already implemented >somewhere. You just need to get all the other dialogs to follow suit. Not entirely, see bug 65119.
I'm not yet convinced that parent-relative coordinates buy a lot, but as Stefan explains, they don't hurt. Note that some widely-used dialogs in Eclipse (for example, Preferences) are not parented, so it won't matter. We know for sure that using display (vs. monitor client) coordinates to remember dialog position causes problems, so I agree with Stefan's solution, and this is the path I'll take. I'll wait for the "hey, I wanted my dialog to cross boundaries" bug to be submitted before trying to fix it. ;-) Many of the multi-monitor bugs result from dialogs that previously coded their own version of "remember last position" in display coordinates, and were never updated to deal with multi-monitors. So providing standard support will help, but it won't be instant, since each dialog will have to be changed to remove the old code. I think there are lurking problems with Window.getConstrainedShellBounds. Use of this default logic is producing an undesirable result for Rob in bug #108801. I'll investigate this and any correction will be made in those Window methods so that all dialogs benefit.
Released changes. Available >20051004. Updated OpenResource and GotoResource to inherit the logic rather than provide their own. Updated WorkbenchPreferencesDialog to remember its location (but not size). Will post info on dialog conversion to platform-ui-dev and also here (in a separate comment below). Specific requests to remember a certain dialog's location and/or size should be made in individual bug reports.
The JFace Dialog class now supports persisting of a dialog's location and/or size. Subclasses are encouraged to migrate to the new behavior and delete any code previously used to persist size and location. (Then all those pesky multi-monitor bugs won't be your fault anymore!). It is still up to you to determine whether persisting location, size, or both make sense for your particular dialog. You won't magically get any behavior without doing something. As a general guideline, persisting the location makes sense when the dialog is fairly global to the workbench. Then the user can place is where he/she wants and it will forever reappear there when opened until explicitly moved. It may not make sense to do this if the dialog is closely related to a view or editor location, which may change. Persisting the size generally makes sense when the dialog layout is fairly static in nature. If it resizes itself according to some internal state (such as multi-page dialogs), it may not make sense to store the size. Here's how it works. (1) Override the method Dialog.getDialogsBoundsSettings() to return the IDialogSettings appropriate for persisting your dialog's bounds. Note that if you have a hierarchy of dialogs, you should override this method at the concrete (leaf) levels. (It may in some cases be appropriate to share the settings in a hierarchy of dialogs whose controls and content are nearly identical, but realize that this would mean each concrete instance will appear in the last location/size of any other instance in the hierarchy). (2) If you want to persist the last known size and location of the dialog, you are done. If you want to persist only the size or only the location, override the method Dialog.getDialogBoundsStrategy() to return the constant indicating what strategy to use. This is a set of bit mask values which are currently defined as DIALOG.PERSIST_LOCATION - persist the last known location of the dialog DIALOG.PERSIST_SIZE - persist the last known size of the dialog Additional strategies may develop as we get feedback on this feature. Ideas include persisting only explicit resizes, persisting locations relative to different coordinates (display, monitor, parent shell), or controlling the way that the bounds are constrained (allowed to cross monitors or constrained to a single monitor)
If you want to request this behavior for a specific dialog, the following bugs have been opened so far: Bug #108801 - Platform dialogs Bug #111650 - JDT dialogs Bug #111652 - Search dialog Bug #111653 - Text dialogs
Just verified with Stefan that the "right" thing is happening in the multi- monitor cases #3 and #4 from comment #15.
Verified on Windows and Mac (single monitor scenarios) on I20051101-1204. Previously verified multi-monitor cases (except for Linux virtual desktop) with Stefan on 10/20 (see comment #21). Considering this verified for M3.
Is there 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.
that's a good point, Markus. Would you mind opening a new bug for this feature?
Sure, it's bug 116906.
