FVWM: 2.4 => 2.5 upgrade breaks xcuckoo
Hello all! I've been using 2.4.20 (under Slackware 13.0) and grown attached to the following functions, which depend on the old Unix program xcuckoo: DestroyFunc SpiffyTerm AddToFunc SpiffyTerm + I Exec terminal + I Exec xcuckoo -window terminal -command 'date "+%a, %b %d - %T"' -update 1 -wait 60 DestroyFunc SpiffyEmacs AddToFunc SpiffyEmacs + I Exec emacsclient -c + I Exec xcuckoo -window 'em...@slack.maistre.ath.cx' -command 'fortune palindromes latin_proverbs german_proverbs proverbs latin_proverbs_2' -wait 60 The first one makes the title of Terminal a digital clock, the second rotates random proverbs, palindromes and whatnot through the emacs title bar. I just tried upgrading to 2.5.28 and both stopped working. A little experimentation shows that the xcuckoo commands work with ancient window managers like twm and mwm but not with more up-to-date ones like fluxbox or windowmaker, or with xfce4. 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). Any other more hopeful ideas? jk
Re: FVWM: 2.4 => 2.5 upgrade breaks xcuckoo
2010/1/8 Jim Kalb : > Hello all! > > I've been using 2.4.20 (under Slackware 13.0) and grown attached to the > following functions, which depend on the old Unix program xcuckoo: If, from my limited googling, this application just updates the window title periodically, it's probably using XSetWMName() or something. That's OK, but like xprop, which will try and do the same thing, not all applications will like or accept this. You might want to ditch xcuckoo though and look into wmctrl -- which was written sometime this century. -- Thomas Adam
Re: FVWM: 2.4 => 2.5 upgrade breaks xcuckoo
> "ta" == Thomas Adam writes: ta> 2010/1/8 Jim Kalb : >> I've been using 2.4.20 (under Slackware 13.0) and grown >> attached to the following functions, which depend on the old >> Unix program xcuckoo: ta> If, from my limited googling, this application just updates ta> the window title periodically, it's probably using ta> XSetWMName() or something. That's OK, but like xprop, which ta> will try and do the same thing, not all applications will ta> like or accept this. ta> You might want to ditch xcuckoo though and look into wmctrl ta> -- which was written sometime this century. Thanks much! It indeed works by updating the window title periodically. It's not a problem with the application though but with the window manager--emacs and Terminal titles get updated just fine in fvwm 2.4, twm and mwm but not in fvwm 2.5, fluxbox, or windowmaker. The manpage says (if relevant): RESOURCES xcuckoo recognises top level resources stored in the RESOURCE_MANAGER property of the server's root window that have the same names as the option keywords, except for display, since the display has to be opened in order to read the property, and version. They are, with their defaults: window:TWM Icon Manager icon: false command: date "+%H:%M" mode: replace separator: update:60 wait: 0 Any value other than true for the icon resource is equivalent to false. Don't know if that rings any bells. If not, I'll look at wmctrl. A quick google suggests it might be used in a script that can do the same thing, although scripting isn't my long suit. Thanks again, jk
Re: FVWM: 2.4 => 2.5 upgrade breaks xcuckoo
2010/1/8 Jim Kalb : > 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. /Viktor
Re: FVWM: 2.4 => 2.5 upgrade breaks xcuckoo
2010/1/8 Jim Kalb : > Don't know if that rings any bells. If not, I'll look at wmctrl. A > quick google suggests it might be used in a script that can do the > same thing, although scripting isn't my long suit. You can probably do it with Fvwm's Schedule command with the Periodic option together with wmctrl. /Viktor
Re: FVWM: 2.4 => 2.5 upgrade breaks xcuckoo
On Fri, Jan 08, 2010 at 05:25:38PM +0100, Viktor Griph wrote: > 2010/1/8 Jim Kalb : > > 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.
Re: FVWM: 2.4 => 2.5 upgrade breaks xcuckoo
2010/1/8 Thomas Adam : > On Fri, Jan 08, 2010 at 05:25:38PM +0100, Viktor Griph wrote: >> 2010/1/8 Jim Kalb : >> > 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. The difference is that before, it would not be set if the EWMH name matched that of the classic WM_NAME exactly, which meant that it was possible to chnage the WM_NAME and have that override the name specified in _NET_WM_NAME. [1] /Viktor [1] http://www.mail-archive.com/fvwm-work...@fvwm.org/msg01954.html
Re: FVWM: 2.4 => 2.5 upgrade breaks xcuckoo
> "vg" == Viktor Griph writes: vg> 2010/1/8 Jim Kalb : >> 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). vg> Can you give fvwm 2.5.27 a try? I think what you are seeing vg> is the result of the "Fvwm now retains utf8 window names vg> when the WM_NAME changes, and the utf8 name converted to vg> the default charset match the old WM_NAME" bug fix in vg> 2.5.28. I just tried that, and the same problem. Xcuckoo doesn't work. I'll have to try wmctrl if I want to upgrade and keep the feature. Thanks, jk
Re: FVWM: 2.4 => 2.5 upgrade breaks xcuckoo
> "vg" == Viktor Griph writes: vg> You can probably do it with Fvwm's Schedule command with vg> the Periodic option together with wmctrl. It worked! The new function definitions under 2.5.28 are: DestroyFunc SpiffyTerm AddToFunc SpiffyTerm + I Exec terminal + I Schedule Periodic 1000 Exec wmctrl -r Terminal -N "Terminal - `date "+%a, %b %d - %T"`" DestroyFunc SpiffyEmacs AddToFunc SpiffyEmacs + I Exec emacsclient -c + I Schedule Periodic 6 Exec wmctrl -r emacs -N "emacs - `fortune palindromes latin_proverbs german_proverbs proverbs latin_proverbs_2`" The effect is the same as the old functions except that I have to put a set string in the title to identify it to wmctrl. On a different topic--are the forum and the wiki likely to reappear soon? jk
Re: FVWM: 2.4 => 2.5 upgrade breaks xcuckoo
On Fri, Jan 08, 2010 at 08:30:24PM -0500, Jim Kalb wrote: > > "vg" == Viktor Griph writes: > > vg> You can probably do it with Fvwm's Schedule command with > vg> the Periodic option together with wmctrl. > > It worked! The new function definitions under 2.5.28 are: > > DestroyFunc SpiffyTerm > AddToFunc SpiffyTerm > + I Exec terminal You'll find "Exec exec" more useful to kick the original shell out the way when the actual command starts. > On a different topic--are the forum and the wiki likely to reappear > soon? Maybe. I can't do everything. -- 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.
