Re: window decoration problem with sawfish and GNOME 2

[John Harper <jsh unfactored org>]

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]);
 	    else
-		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);
 	}
 	break;
     }

thanks for tracking down the problem!

	John