Bugzilla – Full Text Bug Listing
| Summary: | [DetachedView] Undocked/floating windows looses position | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Morten Moeller <morten-lists> | ||||
| Component: | UI | Assignee: | Stefan Xenos <sxenos> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | billy.biggs, christophe.cornu+eclipse, douglas.pollock | ||||
| Version: | 3.0 | Keywords: | helpwanted | ||||
| Target Milestone: | 3.1 M4 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux-GTK | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Morten Moeller
Which build are you using? This doesn't seem to occur on Windows XP. I've tried this on I200402190800, M7, and the code in HEAD on Feb 23, 2004, and cannot reproduce it. I just checked CVS, and it looks like there was a code change on Jan 30 that might have affected the initial window position. If your build is older than Jan 30, it's possible that this has been fixed already. In the meantime, I'll try to find a multimonitor GTK setup to test this on. I currently running N20040222 (from Saturday). I first saw the issue (well first time I tried as well) at the first integration build after M7. If there is any debug information I can turn on to help let me know. Okay, hopefully I'll have access to a multimonitor GTK system tomorrow. :-) I am the aforementioned GTK box, but I'm getting the feeling that we have different set-ups. I'm using nVidia's TwinView functionality which quietly maps two monitors into one large virtual monitor. Are you using a dual monitor server layout? Can you please attach your XF86Config so we can try to duplicate? Thanks. (As a note, using TwinView, this bug is not reproducible on my box.) Created attachment 8160 [details] My XF86Config file The Machine is a Dell Percision 450 with a Radeon VE card with dual DVI outputs. XWindows system: XFree86 Version 4.3.0 (Red Hat Linux release: 4.3.0-2) Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.20-3bigmem i686 [ELF] Build Date: 27 February 2003 Build Host: porky.devel.redhat.com Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.4.20-20.9smp (bhcompile@stripples.devel.redhat.com) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 SMP Mon Aug 18 11:32:15 EDT 2003 PF I'm using xinerama for dual monitoring support, so yes, I would have two actual screens. Hmm... it appears that this is due to a difference in the behavior of SWT on particular GTK setups. BTW, the likely cause is this: when Eclipse creates a detached window, it checks if the window is within the bounds of the Display and moves the detached window back to the monitor containing the main Eclipse window if it doesn't lie anywhere in the display. It is possible that on GTK, SWT is returning a client region for the Display that does not cover all the monitors. I'm not sure if this is a bug or whether we're misusing Display.getClientArea. Reassigning to SWT for comment. Chrix can you comment? It's possibly a bug in Display.getClientArea(). In a multi-monitor situation, it should return the same as Display.getBounds(). You should be using Monitor API to play "shell positioning" games. Re comment 9: Steve is right. We should really begin by checking if the detached view interects the client area of any monitor rather than the client area of the display. If this bug was being caused by having a display area that did not encompass all the monitors, this should fix it. I've submitted a patch that implements comment 10. However, if this fixes the problem then it means that there was definitely a monitor whose client area was outside the range of Display.getClientArea(). Stefan, this doesn't seem like an SWT problem. Can you confirm this? If not, please close this problem report or take ownership. Thanks. If the patch mentioned in comment 11 is in the head and made M8, it did not do anything. If any debug information can be put in and you need my help, please don't hestitate to ask :) Unfortunatly this is one of two bugs (bug 53814 is the other) that renders detached views totally useless for me. Views also doesn't render its content when switching from one perspective to another when they are detached (I have to reattach and unattach again to get the view content back). Reassigning to Stefan Adding the helpwanted tag. Nobody on the UI team can reproduce this on our hardware. Hopefully, someone from the community can step up to the challenge. For anyone who can reproduce this: I believe that org.eclipse.ui.internal.DetachedWindow.getConstrainedShellBounds(...) may be a good place to start looking. I was looking in the area Stefan suggested..
It seems my setup is reporting just one monitor:
Monitor org.eclipse.swt.widgets.Monitor@0 area Rectangle {0, 0, 3200, 1200}
DetachedWindow.getConstrainedShellBounds seems to be correct. It says its
within the monitor and just pases the bounds through. If the window is on the
left monitor, the bounds are set with an X value of less than 1600; right
monitor higher than 1600... But the window always ends up on the monitor that
the main Eclipse window is on.
I still think this is a SWT/GTK level bug and not platform. I will research
more, but if any of you guys that knows this better than me can give me any
more pointers.. that would be great :) ..
Can you post the output of 'xdpyinfo -ext all' on your machine? Just FYI, The card is a ATI Radeon VE card with dual DVI outputs (It is what
Dell ships for dual monitor Linux workstations). My XF86Config file is already
attached (except I changed monitors since then, but the problem is the same).
The XF86Config setup is from ATI and modified to fit my system.
mmoeller@mmoeller:~/Documents> /usr/X11/bin/xdpyinfo
name of display: :0.0
version number: 11.0
vendor string: The XFree86 Project, Inc
vendor release number: 40399902
XFree86 version: 4.3.99.902
maximum request size: 16777212 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
focus: window 0x3800007, revert to PointerRoot
number of extensions: 28
BIG-REQUESTS
DPMS
Extended-Visual-Information
FontCache
GLX
LBX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
RECORD
RENDER
SECURITY
SGI-GLX
SHAPE
SYNC
TOG-CUP
X-Resource
XC-APPGROUP
XC-MISC
XFree86-Bigfont
XFree86-DGA
XFree86-Misc
XFree86-VidModeExtension
XINERAMA
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number: 0
number of screens: 1
screen #0:
dimensions: 3200x1200 pixels (726x272 millimeters)
resolution: 112x112 dots per inch
depths (7): 24, 1, 4, 8, 15, 16, 32
root window id: 0x5e
depth of root window: 24 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x20
default number of colormap cells: 256
preallocated pixels: black 0, white 16777215
options: backing-store NO, save-unders NO
largest cursor: 64x64
current input event mask: 0xda4031
KeyPressMask EnterWindowMask LeaveWindowMask
KeymapStateMask StructureNotifyMask SubstructureNotifyMask
SubstructureRedirectMask PropertyChangeMask ColormapChangeMask
number of visuals: 8
default visual id: 0x23
visual:
visual id: 0x23
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x24
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x25
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x26
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x27
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x28
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x29
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2a
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
forgot -ext all! sorry for the spam in advance.. so it was missing the xinerama
info.
mmoeller@mmoeller:~/Documents> /usr/X11/bin/xdpyinfo -ext all
name of display: :0.0
version number: 11.0
vendor string: The XFree86 Project, Inc
vendor release number: 40399902
XFree86 version: 4.3.99.902
maximum request size: 16777212 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
focus: window 0x3800007, revert to PointerRoot
number of extensions: 28
BIG-REQUESTS
DPMS
Extended-Visual-Information
FontCache
GLX
LBX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
RECORD
RENDER
SECURITY
SGI-GLX
SHAPE
SYNC
TOG-CUP
X-Resource
XC-APPGROUP
XC-MISC
XFree86-Bigfont
XFree86-DGA
XFree86-Misc
XFree86-VidModeExtension
XINERAMA
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number: 0
number of screens: 1
screen #0:
dimensions: 3200x1200 pixels (726x272 millimeters)
resolution: 112x112 dots per inch
depths (7): 24, 1, 4, 8, 15, 16, 32
root window id: 0x5e
depth of root window: 24 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x20
default number of colormap cells: 256
preallocated pixels: black 0, white 16777215
options: backing-store NO, save-unders NO
largest cursor: 64x64
current input event mask: 0xda4031
KeyPressMask EnterWindowMask LeaveWindowMask
KeymapStateMask StructureNotifyMask SubstructureNotifyMask
SubstructureRedirectMask PropertyChangeMask ColormapChangeMask
number of visuals: 8
default visual id: 0x23
visual:
visual id: 0x23
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x24
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x25
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x26
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x27
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x28
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x29
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2a
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
MIT-SHM version 1.1 opcode: 145, base event: 94, base error: 168
shared pixmaps: yes, format: 2
XKEYBOARD version 1.0 opcode: 148, base event: 110, base error: 174
SHAPE version 1.0 opcode: 128, base event: 64
SYNC version 3.0 opcode: 131, base event: 65, base error: 128
system counters: 1
SERVERTIME id: 0x0000005c resolution_lo: 4 resolution_hi: 0
XFree86-DGA version 2.0 opcode: 136, base event: 68, base error: 145
Base address = 0xF0000000, Width = 1600, Bank size = 16777216, RAM size =
16384k
XFree86-VidModeExtension version 2.2 opcode: 134, base error: 130
Monitor Information:
Vendor: Dell, Model: Dell 2001FP (Digital)
Num hsync: 1, Num vsync: 1
hsync range 0: 30.00 - 80.00
vsync range 0: 58.00 - 78.00
Available Video Mode Settings:
Clock Hdsp Hbeg Hend Httl Vdsp Vbeg Vend Vttl Flags
162.00 1600 1664 1856 2160 1200 1201 1204 1250
162.00 1280 1664 1856 2160 1024 1201 1204 1250
162.00 1152 1664 1856 2160 864 1201 1204 1250
162.00 1024 1664 1856 2160 768 1201 1204 1250
Current Video Mode Setting:
162.00 1600 1664 1856 2160 1200 1201 1204 1250
XFree86-Misc version 0.8 opcode: 135, base error: 137
Keyboard Settings- Type: 101-key, Rate: 30, Delay: 500, ServerNumLock: no
Mouse Settings- Device: /dev/input/mice, Type: IMPS/2
BaudRate: 0, SampleRate: 0, Resolution: 0
Emulate3Buttons: no, Emulate3Timeout: 50 ms
ChordMiddle: no, Flags: None
Buttons: 5
XTEST version 2.2 opcode: 147
DOUBLE-BUFFER extension not supported by server
RECORD version 1.13 opcode: 144, base error: 167
XInputExtension version 1.3 opcode: 146, base event: 95, base error: 169
Extended devices :
"Mouse0" [XPointer]
"keyboard" [XKeyboard]
RENDER version 0.8 opcode: 154, base error: 179
Render formats :
pict format:
format id: 0x2b
type: Direct
depth: 1
alpha: 0 mask 0x1
red: 0 mask 0x0
green: 0 mask 0x0
blue: 0 mask 0x0
pict format:
format id: 0x2c
type: Direct
depth: 8
alpha: 0 mask 0xff
red: 0 mask 0x0
green: 0 mask 0x0
blue: 0 mask 0x0
pict format:
format id: 0x2d
type: Direct
depth: 4
alpha: 0 mask 0xf
red: 0 mask 0x0
green: 0 mask 0x0
blue: 0 mask 0x0
pict format:
format id: 0x2e
type: Direct
depth: 32
alpha: 24 mask 0xff
red: 16 mask 0xff
green: 8 mask 0xff
blue: 0 mask 0xff
pict format:
format id: 0x2f
type: Direct
depth: 32
alpha: 0 mask 0x0
red: 16 mask 0xff
green: 8 mask 0xff
blue: 0 mask 0xff
pict format:
format id: 0x30
type: Direct
depth: 24
alpha: 0 mask 0x0
red: 16 mask 0xff
green: 8 mask 0xff
blue: 0 mask 0xff
pict format:
format id: 0x31
type: Direct
depth: 24
alpha: 0 mask 0x0
red: 0 mask 0xff
green: 8 mask 0xff
blue: 16 mask 0xff
pict format:
format id: 0x32
type: Direct
depth: 15
alpha: 12 mask 0xf
red: 8 mask 0xf
green: 4 mask 0xf
blue: 0 mask 0xf
pict format:
format id: 0x33
type: Direct
depth: 15
alpha: 0 mask 0x0
red: 10 mask 0x1f
green: 5 mask 0x1f
blue: 0 mask 0x1f
pict format:
format id: 0x34
type: Direct
depth: 15
alpha: 0 mask 0x0
red: 0 mask 0x1f
green: 5 mask 0x1f
blue: 10 mask 0x1f
pict format:
format id: 0x35
type: Direct
depth: 16
alpha: 12 mask 0xf
red: 8 mask 0xf
green: 4 mask 0xf
blue: 0 mask 0xf
pict format:
format id: 0x36
type: Direct
depth: 16
alpha: 0 mask 0x0
red: 10 mask 0x1f
green: 5 mask 0x1f
blue: 0 mask 0x1f
pict format:
format id: 0x37
type: Direct
depth: 16
alpha: 0 mask 0x0
red: 0 mask 0x1f
green: 5 mask 0x1f
blue: 10 mask 0x1f
pict format:
format id: 0x38
type: Direct
depth: 16
alpha: 15 mask 0x1
red: 10 mask 0x1f
green: 5 mask 0x1f
blue: 0 mask 0x1f
pict format:
format id: 0x39
type: Direct
depth: 16
alpha: 15 mask 0x1
red: 0 mask 0x1f
green: 5 mask 0x1f
blue: 10 mask 0x1f
pict format:
format id: 0x3a
type: Direct
depth: 16
alpha: 0 mask 0x0
red: 11 mask 0x1f
green: 5 mask 0x3f
blue: 0 mask 0x1f
pict format:
format id: 0x3b
type: Direct
depth: 16
alpha: 0 mask 0x0
red: 0 mask 0x1f
green: 5 mask 0x3f
blue: 11 mask 0x1f
pict format:
format id: 0x3c
type: Direct
depth: 32
alpha: 0 mask 0x0
red: 0 mask 0xff
green: 8 mask 0xff
blue: 16 mask 0xff
Screen formats :
Screen 0 (sub-pixel order Horizontal RGB)
filters: nearest, bilinear, fast(nearest), good(bilinear), best(bilinear)
visual format:
visual id: 0x23
pict format id: 0x30
visual format:
visual id: 0x24
pict format id: 0x30
visual format:
visual id: 0x25
pict format id: 0x30
visual format:
visual id: 0x26
pict format id: 0x30
visual format:
visual id: 0x27
pict format id: None
visual format:
visual id: 0x28
pict format id: None
visual format:
visual id: 0x29
pict format id: None
visual format:
visual id: 0x2a
pict format id: None
depth formats:
depth 24
pict format id: 0x30
pict format id: 0x31
depth formats:
depth 1
pict format id: 0x2b
depth formats:
depth 4
pict format id: 0x2d
depth formats:
depth 8
pict format id: 0x2c
depth formats:
depth 15
pict format id: 0x32
pict format id: 0x33
pict format id: 0x34
depth formats:
depth 16
pict format id: 0x35
pict format id: 0x36
pict format id: 0x37
pict format id: 0x38
pict format id: 0x39
pict format id: 0x3a
pict format id: 0x3b
depth formats:
depth 32
pict format id: 0x2e
pict format id: 0x2f
pict format id: 0x3c
XINERAMA version 1.1 opcode: 152
head #0: 1600x1200 @ 0,0
head #1: 1600x1200 @ 1600,0
I dug deeper into this. I'm guessing the binary part of GTK or GTK itself is
doing this to me. Following the pointers from Stefan I followed the shell and
opening it. The bounds are set correctly into the shell, but at shell.open(),
the bounds change automatically! Steping through Shell.open(), this is the
result:
From Shell.java:
public void open () {
checkWidget (); // After call: Bounds are { 400,200,100,100 }
setVisible (true); // After call: Bounds are { 400,200,100,100 } but
shows at { 2000,200,100,100 }
bringToTop (false); // After call: !!! Bounds change to
{ 2000,200,100,100 } !!!
if (!restoreFocus () && !traverseGroup (true)) setFocus ();
}
This must be using the position of the parent shell somehow, because if I have
eclipse on screen 1, the dialogs always open on screen 1 (and open() adds 1600
to the x coordinate of the dialog if needed), if eclipse is on screen 0, it
opens on screen 0.
Now I did manage to do shell.setBounds(2000,200,100,100) after open() and it
repositioned to the correct screen. So I am guessing somewhere within
setVisible(), it, on linux/gtk, checks the bounds of the parent shells screen
and positions it within it? Or maybe gtk itself does this check I don't know..
Wow. I'm really sorry, but I probably should have realized this sooner. KDE tries to centre dialogs over the parent shell. Since we are currently creating our detached views with parents, it will try to centre detached views over the workbench window. Would this accurately describe what you're seeing? Yes, playing a little more its not really monitor related. I make my eclipse window really small (normally its always maximized on one monitor) and it will even loose position within the same monitor now, placing it, as you said, centered over the eclipse window. And yes, I am using KDE as desktop/window manager, so this would explain it. Is this something I can change (if you know) in my kde configuration or does it have to be a code change from Eclipse to make this solved? As far as I know, this has to be fixed in Eclipse. Changing the summary, as this applies to all configurations. Basically, Eclipse just needs to change one line.... I believe there were reasons why this wasn't feasible, even though it really hurts the usability of detached views on Linux. Is this issue still being investigated? Douglas, can you specify the one line Eclipse has to change, so that we could do some testing? Morten, did you find a workaround? I'm a bit frustrated, having bought just yesterday an additional LCD monitor just for eclipse... I assume that the one line fix Doug is referring to would be setting the parent pointer for the detached window's Shell to null. On windows (and probably other platforms), this will allow the detached window to end up behind the main workbench window with no way to bring it in front -- and this is much more severe than losing the window's position, which is very annoying but still usable. Since Eclipse is giving the correct window location to the OS, it sounds like the best we could do is report this bug to GTK and wait for them to fix it. We could also try hacks like "if OS == GTK, then wait 10ms after opening the window and then try to move it again"... but that's really ugly. Does anyone know if this has already been reported to the GTK developers? If so, it would be useful to attach a link here so that we can follow its progress. Or you could make line 51 of DetachedWindow (org.eclipse.ui.workbench)
super(("gtk".equals(SWT.getPlatform())) ? null :
workbenchPage.getWorkbenchWindow().getShell());
A better fix would be possible if SWT provided window manager detection.
To be clear, this bug is KDE specific. Guillaume, are you using KDE? If not, please open a new bug. The policy in KDE is to open dialogs always in the center of their parent window. There are two open KDE bugs which relate to this: 1: http://bugs.kde.org/show_bug.cgi?id=78082 - This complains about KDE's policy, and it may be changed in the future. 2: http://bugs.kde.org/show_bug.cgi?id=59572 - If a dialog is hidden and re-shown, KDE acts as if it is a new window and re-centers it again. This may also be affecting us here. If either of these were changed I think we would benefit. There's another solution: detached views aren't really "dialogs". Modern window managers have a more expressive notion of window types, and so arguably we should be setting detached views as "utility windows", which would have the nice side-effect of making KDE not enforce its dialog policy on them. However, this would require new API from SWT. Billy, I agree with the idea of using window types -- this would let us describe what we want in a high level, and SWT could give us the correct platform-specific behavior. I'm not sure if we'd even need new API -- SWT.TOOL | SWT.NO_TRIM seems to describe what we want, even though it doesn't currently have the desired behavior. I'm sure it can be fixed with some elaborate SWT fix, but wouldn't the fix I
suggest under work as well. I know its hacky, but it fixes the Linux/KDE
issue. After I put it in, the location is remembered perfectly. Just in case I
guess there could be a "only if gtk" check in there as well..
Only thing it does is to check whether open() changes the set bounds and then
redo it if it happens.
DetachedWindow.java:
/*
* Fixes a problem with Linux GTK when KDE is used as window manager.
* It repositions the detached window to center on top of the parent
* application window.
*
* @see org.eclipse.jface.window.Window#open()
*/
public int open() {
if (getShell() == null)
create();
Rectangle bounds = getShell().getBounds();
int ret = super.open();
if (!bounds.equals(getShell().getBounds())) {
getShell().setBounds(bounds);
}
return ret;
}
Morten's patch looks good as a short-term fix. I think Billy has the right idea for the long-term solution. I have committed Morten's patch to HEAD (without modification) and filed bug 79462 and bug 79461 requesting SWT support for Billy's suggestions. Thanks for the help, Morten. Since I can't reproduce this I'd be grateful if you could add a note here once you see this fixed in a build. Sorry I'm late in responding. yes, this works satisfactory in recent Milestones. This issue can be closed in my oppinion. Flagging as verified due to comment 31 |