bug-gnustep
[Top][All Lists]
Advanced

[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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]