[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #21571] Giant blank app-windows under IceWM
From: |
Kargor |
Subject: |
[bug #21571] Giant blank app-windows under IceWM |
Date: |
Mon, 11 Feb 2008 13:59:28 +0000 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 |
Follow-up Comment #7, bug #21571 (project gnustep):
It's probably not an IceWM problem as in "IceWM bug" since other programs
work fine, just GNUStep messes up. And only with decorated windows, so that's
always a workaround-option :-)
I've been working on this for 2 days already; finally found the time to
figure out the Windowmanager and found this bug report right away :-) So at
least the problem is known already. I switched my development-VM over to IceWM
now, because...
The problem for me is that the Asus eeePC comes with IceWM preconfigured,
which means my GNUStep based stuff doesn't work properly on that box :-( Still
haven't figured out what the problem is, though... I see the place where the
border size values are trashed, but I can't make out the reason since it works
with other window managers.
In _checkStyle, we finally get to line 999 in XGServerWindow.m,
and go into the "special double parent" case (ReparentNotify
gave 0/0).
Upon entry, the r/b/l/t are all 0, and wattr is x=4 y=30 width=100
height=100.
After the first run through the loop it's l=4 r=100 t=30 b=100, wattr
unchanged.
The loop terminates, and we get negative offsets.
The problem for me is that I don't know what things are supposed to look like
--- I've never worked with X11 on that level. My guess is that it's a
misunderstanding --- the values given above suggest that 'r' and 'b' are not
offsets or coordinates but the window size, so the subtraction a bit later
screws up. But I guess I'll have to play around with this a bit longer...
seems you people don't have a fix yet :-(
I tried a little quick hack --- if r is negative, make it the same as l; if b
is negative, make it the same as l (not t, because that includes the title
bar). It helped a bit, but not much --- now the window clipping is wrong
(clips off the bottom "t" pixels, estimated from the looks of it), and
apparently does the same on the right but that's just a few pixels, and it
still stores the 65K values into the root window property.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?21571>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [bug #21571] Giant blank app-windows under IceWM,
Kargor <=