xdotool sets _NET_WM_NAME as a STRING when it needs to be set as UTF8_STRING

[gnab-gib-se]

This is odd since #235 has xdotool not searching _NET_WM_NAME, so I'm not sure why it's setting it, but in both cases WM_NAME must be set and searched as ASCII and _NET_WM_NAME must be set and searched as UTF8.

On some window managers having _NET_WM_NAME set as an ASCII STRING results in a blank window title after trying to set the window title with xdotool via:

xdotool set_window --name 'Test' <windowid>

unfortunately the situation isn't any better if you try something like this:

xdotool set_window --name $'\x54\x65\x73\x74' <windowid>

or

xdotool set_window --name $(echo Test | iconv --to-code utf-8) <windowid>

it still ends up setting _NET_WM_NAME as STRING.

While trying to find a workaround I discovered that, annoyingly, wmctrl sets _NET_WM_NAME properly as UTF8_STRING, but it ONLY sets _NET_WM_NAME. Again, xdotool won't search _NET_WM_NAME, and even worse, if your environment supports UTF-8 wmctrl will DELETE the WM_NAME property. This means after using wmctrl, xdotool won't function at all. So wmctrl is out in terms of a workaround if you want to continue to try and use the broken xdotool.

Thankfully xprop can do this properly (hah), but it takes two calls, one to set WM_NAME so xdotool will work, and another to set _NET_WM_NAME so a conforming UTF8 WM will correctly display the window title:

xprop -id <windowid> -set WM_NAME Test
xprop -id <windowid> -f _NET_WM_NAME 8u -set _NET_WM_NAME Test

Sheesh.