The following patch works around the problem for me. The real problem
is twofold:
1. Java is generating __NET_WM_STATE messages with very large X atom
numbers for data[2], that do not correspond to real atoms. I'm not
sure if this is legal or not, or what the numbers might mean if it
is legal. Normally Sawfish would treat a this would be fine,
because if the atom is not found Sawfish's x-atom-name subr
evaluates to nil. However:
2. The atom numbers are so large that they do not fit into a rep_INTP.
This causes the rep_DECLARE1 in x-atom-name (src/functions.c) to
fail and signal the bad-arg error that is the symptom of the
problem.
The patch below doesn't deal with #2 directly. Instead, it catches
the error and, if it is raised, treats atom2 as nil (just as would
happen if the number were smaller and did not refer to an atom). This
should be fine, as long as there are no real X atoms with numbers that
high (0x2000000 and up).
I'm not really familiar enough with the C part of sawfish and rep to
know how to properly fix the problem. One could have x-atom-name also
accept a rep_BIGNUM; however, this would require some work to verify
that the argument is in range before passing it to XGetAtomName.
--- lisp/sawfish/wm/state/wm-spec.jl.orig 2010-05-08 07:05:58.806028157
-0400
+++ lisp/sawfish/wm/state/wm-spec.jl 2010-05-08 07:06:10.585947672 -0400
@@ -543,7 +543,7 @@
((eql (aref data 0) _NET_WM_STATE_ADD) 'add)
((eql (aref data 0) _NET_WM_STATE_TOGGLE)
'toggle)))
(atom1 (x-atom-name (aref data 1)))
- (atom2 (x-atom-name (aref data 2))))
+ (atom2 (condition-case () (x-atom-name (aref data 2)) (bad-arg
nil))))
(when (or (and (eq atom1 '_NET_WM_STATE_MAXIMIZED_VERT)
(eq atom2 '_NET_WM_STATE_MAXIMIZED_HORZ))
(and (eq atom2 '_NET_WM_STATE_MAXIMIZED_VERT)
--
Neil Moore, n...@s-z.org, http://s-z.org/neil/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
