#3 Wrong calculation with LimitPosition

[Bernhard Walle]

Using the LimitPosition feature the window is displayed
inside screen but the left/right/top/bottom window
decoration is outside the screen which looks not good
[the window is not maximized].

I wrote a patch to fix that (attached). I hope you can
apply this in CVS.

[Bernhard Walle]

wmmgr.cc-patch

[Marko Macek]

Logged In: YES
user_id=1814

Icewm explicitly does maximization by putting the window
borders outside
of the screen (like windows, etc).

This is done so that the vertical scrollbar (browser,
editor) appears at the right edge of the screen. (and to
save screen real-estate in the old days).

I suspect the patch is not right.

[Bernhard Walle]

Logged In: YES
user_id=302109

I think you didn't understand what I mean. The bug/patch has
nothing to do with maximization but only when a program
tries to open a window outside of the screen.

This often happens when a program tries to center the dialog
unter the pointer. I recognized it using Aria (download
manager). Start it, place the pointer on the upper-right
corner and press Ctrl-H. Or use xv (the image viewer), place
the pointer and press Ctrl-P.

The patch is far from perfect but better than nothing. With
Gtk it works perfect, with xv not. With Java not, either.

I don't know why but the window size that IceWM know
internally (frame->width() + 2*frame->borderX()) is not
always the same as the real width measured using a screen
ruler. With Gtk it is right, with Java/Swing it is not (two
pixels difference in warp theme). Since this is the source
why it doesn't work 100 % in Java it's not easy to correct.
I don't know if it's a bug in Java or IceWM.

I used following test application:

import javax.swing.*;
class Test {
public static void main (String[] args) {
JFrame frame = new JFrame("Titel");
frame.setLocation(2000, -5);
frame.setSize(100, 300);
frame.setVisible(true);
}
}

The width measured is exactly 100 pixels. The width from
xwininfo plus 2*border is correct true. But the information
from fprintf(stderr, "width: %d, border: %d\n",
frame->width(), frame->borderX()); returned in
YWindowManager::manageClient is incorrect (depends heavily
on the theme).

I can imagine that the reason is that Java sets the whole
window to 100 (including borders) so they nead to draw the
window, measure the border and change the window size. Gtk
sets the width to 100 *plus* borders so they don't have to
resize.

The fact, that the IceWM-size is right if I don't call
frame.setSize() but add only a button and call frame.pack(),
reenforces the thesis. And in this case the behaviour with
my patch on the screen corners is ok just as in Gtk. ...

[Bernhard Walle]

New patch

[Bernhard Walle]

Logged In: YES
user_id=302109

My current patch breaks restoring of maximized applications.
Some apps don't really set `maximized' but set only the old
size/position (testet: Mozilla, Opera). The only application
I know which does correct maximization-restoring is Netbeans.

However, I corrected my patch (using a simple case
discrimination). I attached it.

[Marko Macek]

Logged In: YES
user_id=1814

Your second patch is better. Although I suspect it's still
wrong.
It might be needed only when ConsiderBorderV/H is set.

As for Java. Java API sets the size of outside frame, and
this gives problems in some cases because X requires the
size of internal frame and Java needs to "guess" the size of
window borders. It''a "quality of implementation" issue for
your java VM.

[Bernhard Walle]

Logged In: YES
user_id=302109

It seems that Java guesses the size of border and draws the
window, measures the window and then resizes the few pixels
so that's exactly. Right? (Maybe JDK-dependent.)

> Although I suspect it's still wrong.
Hm, do you think that leaving the concerning border outside
is better? I tested with different applications and I saw no
side effects.

[Marko Macek]

Logged In: YES
user_id=1814

This patch should really be conditional on ConsiderBorderV/H
(which should be merged into one option, probably).

I don't consider it a bug.

[Marko Macek]

Logged In: YES
user_id=1814

In maximized = border outside of the screen.

ConsiderBorderV/H needs to be one option called
FrameVisibleWhenMaximized
defaulting to 0.