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)
CVS griph: * retain utf-8 window names on WM_NAME changes also when they match the
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 09/07/09 23:30:35 Modified files: . : ChangeLog NEWS fvwm : ewmh_names.c Log message: * retain utf-8 window names on WM_NAME changes also when they match the previous WM_NAME after charset conversion, and the utf-8 name was set after the window was first mapped.
CVS griph: * fix _NET_WM_ICON_NAME retention on WM_ICON_NAME change
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 09/07/09 23:39:40 Modified files: . : ChangeLog fvwm : ewmh_names.c Log message: * fix _NET_WM_ICON_NAME retention on WM_ICON_NAME change
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
