On Fri, Jan 08, 2010 at 05:25:38PM +0100, Viktor Griph wrote: > 2010/1/8 Jim Kalb <jimk...@gmail.com>: > > I just tried upgrading to 2.5.28 and both stopped working. > > > > [...] > > > > So I assume that there's some generally-used window manager > > modernization that breaks xcuckoo and probably nothing can be done about > > it short of modifying xcuckoo (not something I'm competent to do). > > Can you give fvwm 2.5.27 a try? I think what you are seeing is the > result of the "Fvwm now retains utf8 window names when the WM_NAME > changes, and the utf8 name converted to the default charset match the > old WM_NAME" bug fix in 2.5.28.
Hmm. I am not so sure. The condition SET_HAS_EWMH_WM_NAME(fw, 1) for that fix was just shifted up -- but it has always been set in fvwm/ewmh_names.c::EWMH_WMName() to True. When a client receives a PropertyNotify event, and the event was for WM_NAME, then we just return immediately from any further processing if the fw window has EWMH_WM_NAME. So the only time a WM_NAME event change can happen from things like xprop and wmctrl can only be when the client isn't listening to such things -- which for most apps is going to be rare. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.
