[compiz] Small questions about recent CVS commit

[Dan Winship]

Quinn Storm wrote:
> The day before yesterday, there were some CVS commits to compiz that
> seem to have created problems.  One is the removal of a call to
> gconfSetOption(sp?) which removes the behaviour of "fixing" options
> that have incorrect values

Oh, did that code do that too? It looked to me like the main intent of
the code was to provide initial values for the gconf settings (if it
tried to read them and found that they weren't yet set), so that after
running the gconf plugin once, you could go into gconf-editor and see
all of the keys. This is now done the *right* way--by providing a
schemas file containing all of the keys with their default values--and
the extra call to gconfSetOption was now causing problems in some cases
because it would get compiz stuck in an infinite loop because it would
set the value of the key every time it got a notification that the value
of the key had been set... I guess the problem is that at that point in
the code it's not clear if "status" is FALSE because it couldn't parse
the value in gconf, or because it parsed it but couldn't set it. In the
former case, calling gconfSetOption would fix the value in gconf, but in
the latter case it would just re-set it to the same value, causing the loop.

Still, is bashing over the user's settings the right behavior here? If I
set the "rotate left" keybinding to
"<Alt><Super<Control><Mod2>XF86ApplicationLeft", it seems like it would
be nicer of compiz to just spew an error message and ignore it, rather
than erasing it and forcing me to retype the whole thing because I
missed a ">", right?

> and the other is some new (experimental?)
> code for focus-stealing prevention that causes things like gnome's
> Alt+F2 run box to appear without focus.

Huh.

Compiz isn't doing full focus-stealing-prevention yet, it's only
checking for windows that explicitly request to not be given the focus.
For some reason, the run dialog is requesting that when compiz invokes
it (although it doesn't do that when metacity invokes it). I'll figure
out what's going on here...

(Btw, there's a a bug in that code that makes it crash on 64bit boxes.
Change "memcpy (&value, data, sizeof (Window));" to "memcpy (&value,
data, sizeof (CARD32));" in getWindowUserTime to fix it. I was going to
send this fix to David yesterday, but it looked like my freedesktop cvs
account was going to be activated imminently so I could commit it
myself, but then it wasn't...)

-- Dan