Community
Participate
Working Groups
This bug also exists in version 3.2 as well as in latest SWT (3.3M2). The bug seems to be related with window decorations when setting/getting of window sizes. When calling setSize() for the first time, it works correctly. However, for the second time (applied to any other window) the height of the window becomes larger. It is always reproducible with all my code. Another problem is with bounds/clientArea (possibly related): shell.setSize(new Point(350, 423)); // appears correctly Point p = shell.getSize(); // returns 350,423 Rectangle r = shell.getClientArea(); // returns 395,345,0,0 - wrong! Rectangle r = shell.getBounds(); // returns 423,350,0,0
Looks like a dup?
Can't find the dup bug unfortunately... Is it really that hard to fix? Maybe I could provide more information on the issue?
OK, guys, according to this discussion: http://dev.eclipse.org/mhonarc/lists/platform-swt-dev/msg00599.html you seem to be pretty well aware of the issue. After debugging SWT GTK code a little bit, I have found out that this initial trimming guess is actual cause of the bug: Display.java: /* Initial Guesses for Shell Trimmings. */ int borderTrimWidth = 4, borderTrimHeight = 4; int resizeTrimWidth = 6, resizeTrimHeight = 6; int titleBorderTrimWidth = 5, titleBorderTrimHeight = 28; int titleResizeTrimWidth = 6, titleResizeTrimHeight = 29; int titleTrimWidth = 0, titleTrimHeight = 23; I understand the problem, however, maybe it would be a good idea to adjust the size of the shell as soon as the new trim values are known? This could be achieved by changing the size again in the Shell.adjustTrim() using the newly set values returned by the gdk_window_get_frame_extents(). However, in my case it always returns {0,0}, so all the windows are smaller the first time and then get larger when created again with the same parameters :-(
I made a mistake stating that gdk_window_get_frame_extents() returns {0,0}. Actually, it returns the same as the following: int width = OS.GTK_WIDGET_WIDTH (shellHandle); int height = OS.GTK_WIDGET_HEIGHT (shellHandle); And results in zeros: OS.gdk_window_get_frame_extents (window, rect); int trimWidth = Math.max (0, rect.width - width); int trimHeight = Math.max (0, rect.height - height); Secondly, it seems to be a bigger problem on Compiz window manager (ver 0.0.13 from FC6). I have just tried it with Metacity and the difference between first and second window sizes are less noticable.
BG isn't around to look at this right now. However, after reading it closely, I don't think there's much we can do. There is no API to get the trim from the window manager. At one point in time, we had code that resized the window to the right size, after it was first displayed using a bad guess. This caused the window to flash and look bad. We decided that it was better that the size be wrong the first time. Any thoughts? I'm sorry but this is looking like WONTFIX.
Should say: "There is no API to get the trim from the window manager, before a window has been opened."
The initial cause of the problem is actually too Windows-centric API :-) By this I mean that window size is set together with border, while in X world window sizes are usually set excluding borders (Window manager later adds whatever is needed). Anyway, a workaround does exist that tries to remember the size of the border after first window is displayed and then reuse it. However, getting the size of border is broken with Compiz (probably a compiz bug?). Recently I have noticed the following code in the Shell.java: /* * Bug in GTK. gdk_window_get_frame_extents() fails for various window * managers, causing a large incorrect value to be returned as the trim. * The fix is to ignore the returned trim values if they are too large. */ if (trimWidth > MAXIMUM_TRIM || trimHeight > MAXIMUM_TRIM) { display.ignoreTrim = true; return; } Maybe trimWidth and trimHeight should be checked for 0 as well? At least this will produce consistent behavior for all windows.
Can you confirm that checking for zero fixes this for Compiz?
"Fixes" would be a wrong word. It just makes window sizes to be more consistent, meaning that if you open the same window (with the same setSize()) several times, it will have the same size every time. Currently windows become larger after the first time they are opened.
Bogdan, can you run Compiz?
I'll track it down and install it and get back with my findings.
FYI, this can still be reproduced with Ubuntu using Compiz and eclipse 3.3.2 swt/jface jars.
The bug doesn't require Compiz - I can reproduce this on RHEL5. There is a X Window atom - "NET_REQUEST_FRAME_EXTENTS" - that might be able to supply the initial size of the window. If this is the case; we can get rid of the hardcoded values.
*** Bug 239201 has been marked as a duplicate of this bug. ***
Created attachment 257438 [details] Size and window bug
On KDE 4.12.4 in commit diff window dialog this bug is very annoying :-(
This should be investigated for 4.9.
I can't reproduce this issue anymore, the size and bounds returned are correct, as well as the client area. The compare window bug was fixed elsewhere.
