Bugzilla – Full Text Bug Listing
| Summary: | [Dialogs] Some dialogs always open on secondary monitor when using dual monitors | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Rob Griffin <rob.griffin> | ||||
| Component: | UI | Assignee: | Susan McCourt <susan> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | sxenos | ||||
| Version: | 3.1 | ||||||
| Target Milestone: | 3.2 M3 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 111653 | ||||||
| Attachments: |
|
||||||
The dialogs that are working properly are those that store their last size and position in settings. Those that are not working properly are those that compute a default size/location on each launch (although I'm not certain why in your case they are appearing on the second monitor.) Up to now, each dialog implements its own scheme for this. The fix for this should be done generally and is being considered in bug #33550. Right now I'm trying to make sure I understand the multi-monitor issues. Once we have some generic support in JFace for this we will pass this bug to individual dialog owners. *** This bug has been marked as a duplicate of 33550 *** Reopening this bug. Remembering size and location will help, but there will still be times that the dialog size and position is no longer valid and must be constrained. After looking closer at the default size and positioning code for dialogs, I want to understand why the dialogs are opening on a different monitor than that of the workbench window. (Note to self: see Window.getConstrainedShellBounds, Window.getClosestMonitor). Could you please describe the workbench window's approximate size/location relative to both monitors? Rob - it would also help if you describe what you would hope/expect to happen with dialogs in these cases: - workbench window is completely on one monitor - should the dialog always pop up on the same monitor? The current code appears to enforce this rule. - workbench window is spread across both monitors - should the dialog also be allowed to spread across both or contain itself to one or the other. If contained to one or the other, how would you expect the monitor to be chosen? I usually have the main window stretched fully across both monitors, occupying the entire width and height of both monitors. I have the Windows taskbar set to hidden and it is located on the left hand edge of my secondary (right-hand) monitor. My expectation is that all dialogs behave like the find/replace dialog, which re-opens to the same position it was in last time. If I move my main window to just one monitor then its probably better to have the dialog open over the main window in this case, otherwise you may not notice the dialog. Also you'll need to check that the saved position is still valid, I've had trouble with a different product in the past when I swapped my secondary monitor from being on the left to being on the right. Dialogs re-opened in a position that was off the edge of the monitor and not visible. (cc'ing Stefan since he knows a lot about this issue and may have insight into whether Window.getConstrainedShellBounds should be changed.) Rob - I've just released the general support for persisting dialog size/location. It should appear in nightly builds after 20051004. At your convenience, can you tell me if the location of the preferences dialog behaves as you expect? It now persists its last known location relative to its parent but constrains itself using the default techniques (to a single monitor). More specifically, could you try spanning the dialog across both monitors and see what happens when you reopen (it will constrain to one of them). This next note is for Stefan and me, and may or may not be of interest to Rob. I think there's a problem in the selection of the monitor to use in Window.getConstrainedShellBounds that could cause Rob's other dialogs to always appear on the secondary monitor. The default bounds logic attempts to place the dialog horizontally and vertically centered to the parent's monitor or primary monitor. But when it goes to actually constrain the dialog, it chooses the monitor based on which one is closest to the proposed center of the dialog. This could be a different monitor than originally selected, bumping it to the wrong monitor. It may make more sense to build the proposed bounds and then constrain it to the same monitor rather than using the center to compute another monitor. Using the parent's monitor allows the SWT implementation with all the platform-specific stuff to be taken into account. Created attachment 27837 [details]
experimental patch for JFace Window
Uses parent's monitor (or primary monitor) to constrain a window instead of the
closest monitor to proposed center point.
Rob - the attached patch might fix the problem for the other dialogs (or it might not.) I agree it would be nice if most dialogs remembered their size/position, but even so, the algorithm for choosing which monitor to constrain to needs to be correct. With this patch I am hoping that even if your positioning is not remembered, the dialogs open on the primary monitor. Can you try it and let me know what happens? Susan, this patch will not fix Rob's problem, and it will break other multimonitor scenarios. In his case, the main window is always in the same spot so its Monitor will always be the same. No matter what logic you pick, any dialog that does not remember its location will always end up back on the original monitor when it reopens. Selecting a different monitor does not fix the problem. The fix is to get these dialogs to save their position. Constraining to the parent shell's monitor is a bug. If a well-behaved dialog computed (or saved) its initial location correctly, this would force the dialog back onto the same monitor as the parent (which is not where the user left it). The JavaDoc on Window.getConstrainedShellBounds says that it adjusts the window such that it does not extend outside its monitor client area, and clients rely on the fact that the bounds will not be modified if they are already satisfactory. BTW, this was definitely the intended behavior of getConstrainedShellBounds. I wrote it. The original version of getConstrainedShellBounds behaved as suggested here (see version 1.16 of Window.java), but it caused bug 58095 (along with detached view issues) and was changed to the current behavior. Thanks for the explanation, Stefan, I figured you would know about the history here. You are right - once the position is saved, the current logic will be preferred. It just happens to cause the initial positioning to be unexpected (on the secondary monitor) in Rob's scenario, since the center point of the proposed bounds is in the secondary monitor. I'm going to keep this bug open for me to look at saving positions for the dialogs Rob lists that are in platform UI, and will pass on to owners of other dialogs when done. I have modified the following dialogs to remember their position and size: SaveAsDialog ChooseWorkspaceDialog (only when created with centerOnMonitor=false) WorkbenchPreferencesDialog OpenResource/GotoResource I've decided to open separate bugs per component so they can be assigned their own milestones, verifications, etc. Bug #111650 - JDT dialogs Bug #111652 - Search dialog Bug #111653 - Text dialogs I'm sure there are others in platform ui, so I'll leave this open for now. Will do a more thorough check on dialogs at a later time. Feel free to annotate this bug with additional requests for platform UI dialogs. (Closing this bug so the work that was done for M3 can be verified. Bug #113282 opened to add new suggestions.) Verify these dialogs for M3: Preferences SaveAs Goto/Open Resource Switch workspace To verify the dialogs on a single monitor system: - check that dialog size/position is remembered when dialog is opened again - a dialog left out of bounds will be moved to be fully visible - a dialog made too big will be shrunk appropriately On multi-monitor setup: - check that a dialog opens on the same monitor where it was closed - check that a dialog left open across two monitors will open on the monitor where it was most prevalent Verified using 20051101-1204 on windows single monitor scenarios. Verified multi-monitor scenarios with Stefan on 10/20/2005 (see bug #33550). |
I have dual monitors of equal size and have Eclipse displayed across both monitors. Some dialogs, such as preferences, always open on my secondary monitor instead of my primary monitor. Even after I reposition them onto my primary monitor the next time they open they are on the secondary monitor again. My setup is the primary monitor is in front of me with the secondary to the right. The dialogs that do this are: Preferences Search Go to line Save all Modified Resources Refactor/Move Refactor/Rename Refactoring Extract Interface Save As Workspace Launcher Generate Javadoc Open Resource Externalize Strings and many more... The ones that don't include Find/Replace Open File Run Debug Clean