2009/7/10 Vincent Lefevre <[email protected]>: > On 2009-07-09 23:33:04 +0100, Thomas Adam wrote: >> I think part of the problem is your continued assertion that WM_NAME >> is used in preference of _NET_WM_NAME, and it's being blind-sighted a >> little. So please, I'd like you to detail step-by-step here, exactly >> what it is we would need to do to reproduce your problem -- then I'll >> take a look and try and verify it. > > OK. > > 1. Open a uxterm and select utf8-title. > 2. printf \\033]0\;abc\\xc3\\xa9\\007 > 3. xprop -id $WINDOWID -set WM_NAME abcdef > 4. xprop -id $WINDOWID | grep WM_NAME > > Step 4 shows: > > _NET_WM_NAME(UTF8_STRING) = 0x61, 0x62, 0x63, 0xc3, 0xa9 > WM_NAME(STRING) = "abcdef" > > _NET_WM_NAME corresponds to "abcé". But fvwm shows the title "abcdef", > i.e. the value of WM_NAME instead of _NET_WM_NAME. > > This is on a Debian/unstable machine with fvwm 1:2.5.27.ds-6.
I've committed a fix for this to CVS. The problem was that fvwm didn't set the flag that _NET_WM_NAME was present, if that name was set to expand to the same name as WM_NAME, and _NET_WM_NAME was not present, or couldn't be converted to the default charset, on the inital mapping of the window. The same was true for _NET_WM_ICON_NAME with WM_ICON_NAME. /Viktor
