gtk2 and german umlauts (utf-8) in the title of a popup window

[emmi]

It took me a while to do some more testing with my x application (binaries removed from this forum) and different window managers:

• fluxbox (with fluxbox-locale installed - dunno yet if that is required): works
• openbox (without openbox-locale installed): works
• flwm (not the default flwm_topside): works
• default flwm_topside: doesn't work

As mentioned before, the "old" flwm_topside in TinyCore 5.4 works as well.

To me this looks like a regression in flwm_topside.

[emmi]

Some updates ...

I found the sources for flwm at https://github.com/tinycorelinux/flwm.git, but I couldn't find any relationship between the tcl versions and the commits in the repository. I found the current sources for fltk, but none for 5.x.

I generated flwm and flwm_topside from the sources and ran them. As before, my demo application does not work with flwm_topside but "works" with flwm. As before aterm with an utf-8 encoded title works with flwm_topside, however, I did't try before, it doesn't work with flwm.

So I added some fprintf's showing the to be printed title. For both, flwm_topside and flwm, it showed the ISO-LATIN1 character 'ü' for my demo application and the utf-8 encoded 'ü' for the aterm.

That is, flwm_topside prints utf-8 encoded titles and flwm doesn't. And vice versa, flwm prints ISO-LATIN1 characters and flwn_topside doesn't.

Obviously there are different ways how the title set in aterm and the title set in my gdk demo application makes it to the windows manager, flwm. I didn't look at aterm. Gtk sets the title in X11 atoms, XA_WM_NAME and _NET_WM_NAME. The latter is set to the utf-8 encoded title, the first to a "compound_text" type of text, which here is a ISO-LATIN1 encoded text.

Flwm only retrieves the XA_WM_NAME atom. This explains why I see the ISO-LATIN1 character 'ü' in my debug output. This also means that aterm sets the utf-8 title in XA_WM_NAME. (I assume, it sets whatever it finds in the -title option.)

Retrieving the _NET_WM_NAME atom is not possible, as it is not supported by the default X11 server, Xvesa. (Which to me also means, that gtk fails to set it, but that doesn't matter, here.)

Because my demo application works on 5.x of tcl, it is very likely that flwm_topside for that version printed the ISO-LATIN1 title. As it
no longer does, it is either a regression in flwm_topside or in fltk's fl_draw(), which is used, here - at least in the sources I have. Without having the sources of flwm and fltk for 5.x it is hard to tell where the regression is.

In the current version, for the title, flwm (left side) uses  draw_rotated90(), defined in Rotated.C. (fltk is configured with --disable-xft, so there is no HAVE_XFT defined when compiling flwm.)

So I changed the sources for flwm_topside to use similar code as in draw_rotated90() that is finally calling draw_rotated() with angle 0 for the title. Now flwm_topside behaves as flwm, which is an acceptable behavior for me (and aterm with an utf-8 title no longer
works, which is OK for me, too).

It seems the default X11 server and flwm do not really support utf-8.

[curaga]

Just noting, the X server does not restrict atoms. You can create arbitrary-named atoms just fine.

[Rich]

Hi emmi

... I found the sources for flwm at https://github.com/tinycorelinux/flwm.git, but I couldn't find any relationship between the tcl versions and the commits in the repository. I found the current sources for fltk, but none for 5.x. ...

Attached is a source package from an earlier time frame. I converted it from  .tgz  to  .tar.bz2  so it would be small enough that I
could attach it. The files in  flwm-1.14.tar.bz2  were last modified in 2010 and are likely from TC2 and TC3.

If you look here:
http://tinycorelinux.net/4.x/x86/release/src/
you'll find  flwm-1.14.tgz  and  flwm_topside-1.14.tgz.  These packages contain files with 2012 modification dates and were likely
used for TC5 as well as TC4.

Ignore the  1.14  version number on all of the packages I mentioned. The 3 packages all have differences.

[emmi]

Just noting, the X server does not restrict atoms. You can create arbitrary-named atoms just fine.

Not being an X11 programmer and _NET_WM_NAME not being in /X11/Xatom.h I  incorrectly concluded, that it isn't supported. From what you say, gtk can set this atom and in deed it does. I tried XGetAtoms() for_NET_WM_NAME and it returned an atom, which I then used with getProperty(), which in turn got me the utf-8 title.

Dunno if this is the right way to do this, but it enables me to write a fix and not just a hack or workaround.

[emmi]

This works for me, but a more experienced X11 programmer should review it.

Code: [Select]

diff --git a/Frame.C b/Frame.C
index a52d314..383ea51 100644
--- a/Frame.C
+++ b/Frame.C
@@ -508,6 +508,15 @@ Frame::~Frame() {
 void Frame::getLabel(int del) {
   char* old = (char*)label();
   char* nu = del ? 0 : (char*)getProperty(XA_WM_NAME);
+// fl_draw() works with utf-8, draw_rotated90() does not
+#if defined TOPSIDE || defined HAVE_XFT
+  Atom a = XInternAtom(fl_display, "_NET_WM_NAME", True);
+  if (a != None && a != BadValue && a != BadAlloc) {
+    char *utf8 = del ? 0 : (char*)getProperty(a);
+    if (utf8)
+      nu = utf8;
+  }
+#endif
   if (nu) {
     // since many window managers print a default label when none is
     // given, many programs send spaces to make a blank label.  Detect