Re: window decoration problem with sawfish and GNOME 2

[David Mosberger <davidm napali hpl hp com>]

>>>>> On Wed, 29 Oct 2003 11:24:15 -0800, John Harper <jsh unfactored org> said:

  John> Hi, On Oct 29, 2003, at 11:14 AM, David Mosberger wrote:
  >> OK, I'll look into this.  Since I'm working remotely today, I had
  >> to find a new way to debug this issue and that made me try Xnest
  >> (never used it before).  It works beautifully and that way it's
  >> much easier to see what's going on.  In particular, I now noticed
  >> that sawfish prints a bunch of "Bad argument" messages:

  >> Bad argument: #<subr make-vector>, 73786976294838206464, 1 Bad
  >> argument: #<subr make-vector>, 73786976294838206464, 1 Bad
  >> argument: #<subr make-vector>, 73786976294838206464, 1 Bad
  >> argument: #<subr make-vector>, 73786976294838206464, 1 Bad
  >> argument: #<subr make-vector>, 73786976294838206464, 1

  >> Do you think these might be related to the decoration problem?

  John> yes, almost certainly. I vaguely remember something similar
  John> happening on other 64 bit architectures, which has been
  John> fixed. It may be worth trying the version of librep from cvs
  John> to see if it fixes the problem ("cvs
  John> -d:pserver:anonymous anoncvs gnome org:/cvs/gnome login; cvs
  John> -d:pserver:anonymous anoncvs gnome org:/cvs/gnome co librep")

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.

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?  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:

--- src/functions.c-old	2003-10-29 19:08:00.923700545 -0800
+++ src/functions.c	2003-10-29 18:52:59.470071941 -0800
@@ -705,7 +705,7 @@
 	    if (type == XA_ATOM && (name = x_atom_symbol (l_data[i])) != Qnil)
 		rep_VECTI(ret_data, i) = name;
 	    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] & 0xffffffff);
 	}
 	break;
     }

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.

	--david