Re: window decoration problem with sawfish and GNOME 2

On Oct 29, 2003, at 7:13 PM, David Mosberger wrote:
OK, I now have some idea of what's going on.  The problem is caused by
the _NET_WM_DESKTOP property.  When the gnome-panel is running, the
panel has this property set to a value of 0xffffffff (display on all
desktop spaces).  However, on 64-bit platforms, sawfish ended up
reading it as 0xffffffffffffffff, so that the test against #xffffffff
in wm-spec.jl failed and from there on, things went downhill.

ugh.. (I always disliked that 0xfffffffff magic number..)

I always get confused by X11's weird handling of long, but clearly
what's happening is that XGetWindowProperty() does return a long value
of 0xffffffffffffffff.  I think that makes some sense because it
promises to return the values as a "long" (not "unsigned long"), so
the sign-extension from 32 to 64 bits would naturally cause that (and
I did verify that, on 64-bitplatforms, libX11's _XRead32() function
forces the sign-extension).  I don't remember exactly what X11's
definition of property-type CARDINAL is.  Perhaps it's defined to be a
32-bit unsigned integer?

I'm fairly sure it's defined to be unsigned

If so, I think sawfish needs to take this
into account and truncate the value returned by XGetWindowProperty().
What I do know is that this patch:

-		rep_VECTI(ret_data, i) = rep_make_long_uint(l_data[i]);
+		rep_VECTI(ret_data, i) = rep_make_long_uint(l_data[i] & 0xffffffff);

fixes the decoration problem.  What I don't know is (a) whether this
is the proper fix (does sawfish every read a properties whose value is
a _signed_ integer?) and (b) what changed between Debian/stable and
Debian/unstable to trigger this problem.

I think I would add an extra case for XA_INTEGER:

@@ -704,8 +704,10 @@ symbols, representing the atoms read.
 	    repv name;
 	    if (type == XA_ATOM && (name = x_atom_symbol (l_data[i])) != Qnil)
 		rep_VECTI(ret_data, i) = name;
+	    else if (type == XA_INTEGER)
+		rep_VECTI(ret_data, i) = rep_make_long_int(l_data[i]);
-		rep_VECTI(ret_data, i) = rep_make_long_uint(l_data[i]);
+ rep_VECTI(ret_data, i) = rep_make_long_uint(l_data[i] & 0xffffffffUL);

thanks for tracking down the problem!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]