Support UTF-8 in window titles

[ghost]

I'm not sure if this is a reasonable feature request. UTF-8 is ubiquitous, especially on Linux, and it's so widely supported that actually not supporting it in modern programs requires effort. But I know IceWM is pretty old and behind.

[Code7R]

Which request do you mean? I cannot find any in your text.

Icewm itself supports UTF-8 just like most regular Unix applications, i.e. pass-through. I can run "xtermset -T Böse" (ö is UTF-8, for sure) and it appears exactly how I expect it.

What Icewm does not handle is fallback to alternative fonts if the primary font does not support some glyphs. That's unfortunate but for most people it's ok to use a primary font that covers most charsets in their area.

All said things refer to icewm using Xft, of course. The (legacy) Core font renderer has some issues, so make sure not to use core fonts.

[ghost]

Ah, indeed it does. I was aware that IceWM could show some non-ASCII characters (like umlauts), while it didn't show others, so I this explains it. I was guessing it was doing some Latin1 conversion or so.

Maybe it would be possible to update the font renderer? I suppose running Pango on top of Xft could work.

[bbidulock]

Some UTF-8 errors and problems with localization were fixed in issues #7 and #9. IceWM in fact uses Xft (for those nice anti-aliased fonts) and fribidi libraries which is all that pango offers (with the exception of embedded pango markup). The only thing that IceWM is not so good at (that Blackbox is way better) is conversion of localized character sets to UTF-8. This can cause some problems with lanuguages that are not well represented in ISO 10646 character sets or require special display (e.g. right-to-left, top-to-bottom). If you stick with a .utf8 locale and a decent character set, as @Code7R says, you should be fine. If you notice any defects under that situation that is not explained by character set, please report them. Otherwise, can we consider this issue closed?

[ghost]

I'd be mostly interested in font substitution, so that even if the selected font does not contain a certain glyph, the renderer would fallback to a different font. From what I'm aware, Pango supports this, even when using Xft interop (but I haven't actually checked).

I'm not interested in conversion from legacy charsets, but obviously IceWM should read the more more modern UTF-8 window title properties (I think _NET_WM_NAME instead of WM_NAME?).

At the very least, it could show a replacement character if a font glyph is missing, instead of just pretending that the character doesn't exist.

[bbidulock]

Take a look at the code, or at least at COMPLIANCE. Also, as @Code7R's comment above, UTF-8 is supported in titles, icon names, menus, and everywhere in the wm-spec-1.5 (EWMH/NetWM) and freedesktop.org specifications. IceWM already does what you are asking, and more.

Are you actually running this forked version of IceWM? Support for these things was one of the major reasons for the fork in the first place.

[ghost]

I'm using the Debian unstable package, and the version in the about box contains 960629d, which seems to match with the hash of the latest commit in this repo. It says CodeSet: UTF-8 and Language: en_US.UTF-8.

[danfe]

The only thing that IceWM is not so good at (that Blackbox is way better) is conversion of localized character sets to UTF-8.

Maybe that's the culprit, IceWM is more strict while the *box family are more forgiving? I'm running both the latest versions of Openbox and IceWM on different machines. I've never seen a garbled window title with any program on the former, but occasionally do on the latter. For example, MPlayer and Falkon browser display titles with Cyrillic text correctly, but links -g (Links browser in graphical mode) does not.

To set the window title to some arbitrary UTF-8 string (in a properly set up, fonts- and locale-wise UTF-8 environment), under Openbox it is enough to simply say xprop -set WM_NAME Φμβαρ. To do the same under IceWM one has to call echo Φμβαρ | iconv -f latin1 | xargs xprop -set WM_NAME.

I've found an old bug report from 2005, interestingly talking about UTF-8 being broken again in window titles. Someone says that in rxvt, the title is incorrect, while with xterm it is correct. For me today, on modern IceWM 2.9.7 and xterm-372, -T would set wrong UTF-8 title, but rxvt-unicode-9.30 would set it correctly. :-)

[gijsbers]

links does not use the EWMH properties. It sets its title only in WM_NAME with COMPOUND_TEXT type. Icewm doesn't support COMPOUND_TEXT. Your xprop example also uses COMPOUND_TEXT. Why don't you make it use UTF? If COMPOUND_TEXT is what you want, you can open a new issue and motivate your need for COMPOUND_TEXT support in icewm. But why doesn't links support the EWMH standard? If it would, then we wouldn't be having this discussion. Note that EWMH 1.2 is from 2002-10-06. Hence links -g is 20 years behind. Can you ask the links developer for proper EWMH support? Shouldn't be too much work.

[danfe]

links [...] sets its title only in WM_NAME with COMPOUND_TEXT type.

Apparently so.

IceWM doesn't support COMPOUND_TEXT.

That's fine with me. :-)

Your xprop example also uses COMPOUND_TEXT. Why don't you make it use UTF?

Well, there were two examples. When called without iconv pipe and passed non-Latin string, it would indeed set WM_NAME(COMPOUND_TEXT). If I convert the string, or specify -f WM_NAME 8s, it would be set as (STRING) and displayed correctly. Yesterday I haven't noticed that it prefers compound text by default.

If COMPOUND_TEXT is what you want, you can open a new issue and motivate your need for COMPOUND_TEXT support in IceWM.

No, that's not what I want or really care about. I just want to see non-garbled window titles in all programs, both old and new. Like Openbox does*. ;-)

But why doesn't links support the EWMH standard? Can you ask the links developer for proper EWMH support? Shouldn't be too much work.

Good question and suggestion; I'll see what I can do.

If it would, then we wouldn't be having this discussion.

Well, Links is not the only one; xterm -T also sets WM_NAME(COMPOUND_TEXT) when passed non-Latin title. If IceWM never supported compound text, why did this work in 2005, when xterm was not broken but urxvt was? (Today situation is the opposite.)

*) Unless it does so by violating the standard.

[gijsbers]

Can you evaluate this? Works for me in all cases.

[gijsbers]

Apropos, links -g also has the problem that its bitmap id in its WM_HINTS property is unusable. This makes its icon invisible, which is confusing when minimizing to desktop is enabled.

[danfe]

Can you evaluate this? Works for me in all cases.

I've applied the 533893f patch, rebuilt and restarted IceWM, and now all windows have correct titles, Links included, brilliant! Thank you! xprop -set WM_NAME Φμβαρ, xterm -T, and urxvt -T also all work.

Apropos, links -g also has the problem that its bitmap id in its WM_HINTS property is unusable. This makes its icon invisible, which is confusing when minimizing to desktop is enabled.

I confirm. The icon is also missing when Alt-Tab'ing. Another reason to drop a note to its developers.

[danfe]

I've noticed one problem with MPlayer: when playing non-Latin-named video with use-filename-title=yes setting, in the window title, Alt-Tab window, and task-bar-hover-on label it is displayed correctly, but in the task bar it is garbled. I can attach a screenshot unless you can reproduce it yourself.

[gijsbers]

Yes please, and also the output of xprop | grep -e WM_NAME -e WM_ICON.

[danfe]

Yes please,

and also the output of xprop | grep -e WM_NAME -e WM_ICON.

WM_ICON_NAME(STRING) = "Hon förtjänar hela himlen (Lisa Ekdahl).mp4"
_NET_WM_NAME(UTF8_STRING) = "Hon förtjänar hela himlen (Lisa Ekdahl).mp4"
WM_NAME(STRING) = "Hon förtjänar hela himlen (Lisa Ekdahl).mp4"

[gijsbers]

Looks like a utf8 string encoded as utf8 and hence a mplayer bug. For the titlebar icewm uses _NET_WM_NAME, but for the task button it prefers the icon name.

[danfe]

... and hence an mplayer bug

Okay, but prior to 533893f, currently played movie name had been shown correctly both in the window title and the task bar. Did it just work by accident, or it is a regression that ought to be fixed? I'm wondering because the xprop | grep -e WM_NAME -e WM_ICON output is the same against vanilla 2.9.7 vs. patched. For example, this is for mplayer Φμβαρ.mp4:

WM_ICON_NAME(STRING) = "ΦμβαÏ\302\201.mp4"
_NET_WM_NAME(UTF8_STRING) = "Φμβαρ.mp4"
WM_NAME(STRING) = "ΦμβαÏ\302\201.mp4"

[gijsbers]

OK try this. Can you test the current repository? The grouping menu now is updated when tasks come and go.

[danfe]

OK try this.

Now all programs' titles seem correct everywhere, thanks!

The grouping menu now is updated when tasks come and go.

You mean, if I e.g. type sleep 5 && xterm somewhere, click on the xterm group on the task bar, it will grow by one new item after five seconds? Yeah, I can see it. I'm not sure how actually useful it is, but now its behavior is consistent with the Alt-Tab window, which also gets updated in this case, so I guess it makes sense to have this consistency.

Once question, however: apparently it always grows on the bottom (appended to the list as the last item), which looks good and logical if the TaskBarAtTop=1. Mine is on the bottom, so I'd expect the new menu item would appear on the top of the list (as the first item). Right now it overlaps the taskbar, which is somewhat weird.

[gijsbers]

There is a race condition between the user clicking on a menu item and changing the number of menu items. The click may go to an unexpected entry instead. Hence the menu can only extend from the bottom. You can however use the mouse wheel to scroll the menu.

[danfe]

There is a race condition between the user clicking on a menu item and changing the number of menu items. The click may go to an unexpected entry instead. Hence the menu can only extend from the bottom.

Okay, but that handles the case when new windows come (appear). In the go case (windows deleted), the clicking race condition still has to be taken care of somehow (i.e. fixed, mitigated, or ignored) regardless of the task bar location, no?

[gijsbers]

Yes, if the window is deleted, then its entry in the menu is made passive and grayed out.