Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 350226

Summary: Bad initial workbench window location
Product: [Eclipse Project] Platform Reporter: Markus Keller <markus.kell.r>
Component: UIAssignee: Platform UI Triaged <platform-ui-triaged>
Status: VERIFIED FIXED QA Contact: Eric Moffatt <emoffatt>
Severity: normal    
Priority: P3 CC: bsd, daniel_megert, emoffatt, prakash
Version: 4.2   
Target Milestone: 4.2 M3   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Patch to change default values for Window.{x,y,width,height} none

Description Markus Keller CLA 2011-06-24 06:12:50 EDT
On the first start with 4.1, the workbench window showed up in the very top-left corner (behind the taskbar, which I have on the left).
Comment 1 Markus Keller CLA 2011-06-27 06:17:07 EDT
Version: 4.1.0
Build id: I20110620-1631
Comment 2 Markus Keller CLA 2011-08-26 08:33:12 EDT
Still broken in M20110817-2001.
Comment 3 Brian de Alwis CLA 2011-09-08 11:29:55 EDT
Created attachment 203006 [details]
Patch to change default values for Window.{x,y,width,height}

Since we don't expose EMF's eIsSet() through our interfaces, the following patch (1) adjusts the Window defaults for x, y, widght, and height to −1, to indicate "unknown", and (2) changes WBWRenderer to only override the window's bounds settings where set.
Comment 4 Eric Moffatt CLA 2011-10-18 15:32:57 EDT
Thanks Brian, with this patch how do the various platforms behave ? My main concern is with the width / height which were explicitly defaulted in 3.x.

+1 that we certainly shouldn't be hard-coding the position...
Comment 5 Brian de Alwis CLA 2011-10-28 00:00:25 EDT
(In reply to comment #4)
> Thanks Brian, with this patch how do the various platforms behave ? My main
> concern is with the width / height which were explicitly defaulted in 3.x.
> 
> +1 that we certainly shouldn't be hard-coding the position...

What width & height defaults were we using in 3.x?

Prior to this patch, we were defaulting height / width values to 0, and as a result were simply passing 0 on to Shell#setBounds().  With this patch, we maintain the current height / width if not set.  So we should be in no worse a situation than we were previously.
Comment 6 Brian de Alwis CLA 2011-11-01 10:51:33 EDT
And of course in my testing, my monitors were setup such that the X and Y were > 0, even when multiheaded.  But now I have the monitors switched around, the X and Y can be < 0, causing the windows to be relocated to the principal monitor (bug 358627).
Comment 8 Brian de Alwis CLA 2011-12-06 17:03:27 EST
Verified for M4