fvwm displays the title provided by WM_NAME instead of _NET_WM_NAME
Hi, This was reported by a Debian user. Please retain 339586-forwar...@bugs.debian.org in your responses, so that the Debian BTS may have a copy of your response. ICCCM specifies WM_NAME, as an uninterpreted string, in the latin-1 domain, I think, EWMH specifies _NET_WM_NAME as utf-8; also Note that freedesktop.org WM spec already defines _NET_WM_ICON_NAME _NET_WM_NAME both of type UTF8_STRING, to be used in preference to WM_ICON_NAME and WM_NAME. (http://freedesktop.org/Standards/wm-spec/1.3/ar01s05.html and http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2506989) Fvwm should support the _NET_WM* properties. Currently, in ISO-8859-1 locales, when one has (due to a gtk+ bug): WM_NAME(STRING) = Bug 160236 - no window title if none of the *_NAME properties are set - Mozilla Firefox _NET_WM_NAME(UTF8_STRING) = 0xe2, 0x82, 0xac, 0x20, 0x2d, 0x20, 0x4d, 0x6f, 0x7a, 0x69, 0x6c, 0x6c, 0x61, 0x20, 0x46, 0x69, 0x72, 0x65, 0x66, 0x6f, 0x78 fvwm shows the title Bug 160236 ... corresponding to WM_NAME instead of the one corresponding to _NET_WM_NAME (which has a Euro symbol). Please see https://bugzilla.mozilla.org/show_bug.cgi?id=315947 for more information. xprop -id 0x1c000b8 | grep NET_WM_NAME | \ perl -ne 'while (/(0x[0-9a-f]{2})/g) { printf %c, hex $1 }' (with the id of the corresponding window) gives: Bug 315947 – Window title not updated when a character of the title is outside the WM charset - Iceweasel but FVMW shows the title from WM_NAME instead, which is completely different. manoj ps: 4.1.2.1. WM_NAME Property The WM_NAME property is an uninterpreted string that the client wants the window manager to display in association with the window (for example, in a window headline bar). The encoding used for this string (and all other uninterpreted string properties) is implied by the type of the property. The type atoms to be used for this purpose are described in section 2.7.1. http://tronche.com/gui/x/icccm/sec-2.html#s-2.7.1 says: STRING as a type or a target specifies the ISO Latin-1 character set plus the control characters TAB (octal 11) and NEWLINE (octal 12). -- If you continually give you will continually have. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: fvwm displays the title provided by WM_NAME instead of _NET_WM_NAME
2009/7/9 Manoj Srivastava sriva...@golden-gryphon.com: Hi, This was reported by a Debian user. Please retain 339586-forwar...@bugs.debian.org in your responses, so that the Debian BTS may have a copy of your response. ICCCM specifies WM_NAME, as an uninterpreted string, in the latin-1 domain, I think, EWMH specifies _NET_WM_NAME as utf-8; also Note that freedesktop.org WM spec already defines _NET_WM_ICON_NAME _NET_WM_NAME both of type UTF8_STRING, to be used in preference to WM_ICON_NAME and WM_NAME. (http://freedesktop.org/Standards/wm-spec/1.3/ar01s05.html and http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2506989) But _NET_WM_NAME is used via ewmh_name.c:EWMH_WMName() -- this gets called from add_window.c:setup_window_name(). The EWMH_WMName() function uses FiconvUtf8ToCharset() which is our own wrapper around iconv to convert the given UTF8 string to the current charset the system is set to -- be it Latin-1 or indeed UTF8. Has this been verified with FVWM 2.5.28 (CVS, basically)? The test case works fine here: [n6ta...@shuttle][~]% xprop -id 0x428 | grep NET_WM_NAME | \ perl -ne 'while (/(0x[0-9a-f]{2})/g) { printf %c, hex $1 }' urxvt% -- Thomas Adam
Re: fvwm displays the title provided by WM_NAME instead of _NET_WM_NAME
2009/7/9 Thomas Adam thomas.ada...@gmail.com: 2009/7/9 Manoj Srivastava sriva...@golden-gryphon.com: Hi, This was reported by a Debian user. Please retain 339586-forwar...@bugs.debian.org in your responses, so that the Debian BTS may have a copy of your response. ICCCM specifies WM_NAME, as an uninterpreted string, in the latin-1 domain, I think, EWMH specifies _NET_WM_NAME as utf-8; also Note that freedesktop.org WM spec already defines _NET_WM_ICON_NAME _NET_WM_NAME both of type UTF8_STRING, to be used in preference to WM_ICON_NAME and WM_NAME. (http://freedesktop.org/Standards/wm-spec/1.3/ar01s05.html and http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2506989) But _NET_WM_NAME is used via ewmh_name.c:EWMH_WMName() -- this gets called from add_window.c:setup_window_name(). The EWMH_WMName() function uses FiconvUtf8ToCharset() which is our own wrapper around iconv to convert the given UTF8 string to the current charset the system is set to -- be it Latin-1 or indeed UTF8. Has this been verified with FVWM 2.5.28 (CVS, basically)? The test case works fine here: [n6ta...@shuttle][~]% xprop -id 0x428 | grep NET_WM_NAME | \ perl -ne 'while (/(0x[0-9a-f]{2})/g) { printf %c, hex $1 }' urxvt% Oh -- and I ought to mention, the application itself has to understand UTF8 since it sets the _NET_WM_NAME XAtom in the first place. You can do this for yourself (I assume you're running under a UTF8 locale, etc., already): 1. Start up xterm. 2. unset PROMPT_COMMAND 3. printf \\033]0\;\%s\\007 Hello: ßßß 4. xprop -id $WINDOWID | grep _NET_WM_NAME (will show nothing,) 5. CTRL-right-click on the XTerm window and select UTF8 titles 6. Repeat step 3. 7. Repeat step 4. 8. _NET_WM_NAME(UTF8_STRING) = 0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x3a, 0x20, 0x20, 0xc3, 0x9f, 0xc3, 0x9f, 0xc3, 0x9f And you'll see Hello: ßßß -- with three German ss symbols. If this isn't even close to what you're describing, or you have something completely different, then do say, and where possibly provide steps on how to reproduce your problem, and/or provide a sample FVWM configuration. -- Thomas Adam
Re: fvwm displays the title provided by WM_NAME instead of _NET_WM_NAME
2009/7/9 Vincent Lefevre vinc...@vinc17.org: On 2009-07-09 22:43:55 +0100, Thomas Adam wrote: Oh -- and I ought to mention, the application itself has to understand UTF8 since it sets the _NET_WM_NAME XAtom in the first place. You can do this for yourself (I assume you're running under a UTF8 locale, etc., already): No, on my machine, fvwm runs under ISO-8859-1 locales (IIRC because of a spacing problem under UTF-8). But you don't need UTF-8 locales to understand UTF-8! I know that. And running under a Latin-1 locale, FVWM is displaying all the right characters for me -- accents and all (especially so, since the string stored in the WM_NAME XAtom differs from that in _NET_WM_NAME -- quelle surprise.) 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. -- Thomas Adam
Re: fvwm displays the title provided by WM_NAME instead of _NET_WM_NAME
On 2009-07-09 22:43:55 +0100, Thomas Adam wrote: Oh -- and I ought to mention, the application itself has to understand UTF8 since it sets the _NET_WM_NAME XAtom in the first place. You can do this for yourself (I assume you're running under a UTF8 locale, etc., already): No, on my machine, fvwm runs under ISO-8859-1 locales (IIRC because of a spacing problem under UTF-8). But you don't need UTF-8 locales to understand UTF-8! -- Vincent Lefèvre vinc...@vinc17.org - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Re: fvwm displays the title provided by WM_NAME instead of _NET_WM_NAME
2009/7/10 Vincent Lefevre vinc...@vinc17.org: 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