Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Title bar don't support Unicode #826

Closed
totaam opened this issue Mar 24, 2015 · 26 comments
Closed

Title bar don't support Unicode #826

totaam opened this issue Mar 24, 2015 · 26 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Mar 24, 2015

Issue migrated from trac ticket # 826

component: client | priority: minor | resolution: fixed

2015-03-24 04:20:48: John1221 created the issue

Server: Trusty with xpra 0.15 r8802
Client: MS Windows 7 with xpra 0.15 r8826

Title bar don't support Unicode. Unicode chars become '?' char.
Previous version as 0.14.x support Unicode very well.
@totaam
Copy link
Collaborator Author

totaam commented Mar 24, 2015

2015-03-24 04:49:54: antoine changed status from new to assigned

@totaam
Copy link
Collaborator Author

totaam commented Mar 24, 2015

2015-03-24 04:49:54: antoine commented

Thanks for the bug report.
Python3 support (#90 / #640) makes this such a pain.

@totaam
Copy link
Collaborator Author

totaam commented Apr 15, 2015

2015-04-15 05:20:38: antoine changed status from assigned to new

@totaam
Copy link
Collaborator Author

totaam commented Apr 15, 2015

2015-04-15 05:20:38: antoine changed owner from antoine to John1221

@totaam
Copy link
Collaborator Author

totaam commented Apr 15, 2015

2015-04-15 05:20:38: antoine commented

I'm not seeing any problems with 0.14 or 0.15 on Linux.
It doesn't work on MS Windows, but it never has - see #526.

@john1221: what do you mean by "previous as 0.14.x support Unicode very well".

@totaam
Copy link
Collaborator Author

totaam commented Apr 16, 2015

2015-04-16 03:16:41: John1221 changed owner from John1221 to antoine

@totaam
Copy link
Collaborator Author

totaam commented Apr 16, 2015

2015-04-16 03:16:41: John1221 commented

Replying to [comment:2 antoine]:

I'm not seeing any problems with 0.14 or 0.15 on Linux.
It doesn't work on MS Windows, but it never has - see #526.
But I saw it works. My server is trusty and my client is MS Windows 7.
And It will work if I use xpra 0.14.x at both server and client or server(0.15), client(0.14.x).
(Server 0.15, client 0.15) or (server 0.14.x, client 0.15) don't work.
Do you have already tested with these cases ?
@john1221: what do you mean by "previous as 0.14.x support Unicode very well".
I mean all of xpra 0.14.x versions.
I tested this bug like this:

  • www.google.com
  • Find with keyword "â ậ ấ ầ ẩ ẫ á à ạ ã ả ê ệ ế ề ể ễ ẹ é è ẻ ẽ ô ộ ố ồ ổ ỗ ọ ó ò ỏ õ"
  • See the title.
    Hope this helps.

@totaam
Copy link
Collaborator Author

totaam commented Apr 21, 2015

2015-04-21 17:28:56: antoine uploaded file debug-window-title.patch (2.2 KiB)

patch useful for debugging

@totaam
Copy link
Collaborator Author

totaam commented Apr 21, 2015

2015-04-21 17:56:12: antoine changed status from new to assigned

@totaam
Copy link
Collaborator Author

totaam commented Apr 21, 2015

2015-04-21 17:56:12: antoine commented

Applying the patch above to both branches and comparing the output with diff:

 atvar=@title@
 var=title
 default_value=<untitled window>
-type(Find with keyword "â ? ? ? ? ? á à ? ã ? ê ? )=<type 'str'>
-value=Find with keyword "â ? ? ? ?? á à ? ã ? ê ?
-=Find with keyword "â ? ? ? ? ? á à ? ã ? ê ?
+type(Find with keyword "â ? ? ? ? ? á à ? ã ? ê ? ? ? ?)=<type 'str'>
+value=Find with keyword "â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
+=Find with keyword "â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
 atvar=@client-machine@
 var=client-machine
 default_value=<unknown machine>
 type(desktop)=<type 'str'>
 value=desktop
 =desktop
-title after substitution=Find with keyword "â ? ? ? ? ? á à ? ã ? ê ?  on desktop
+title after substitution=Find with keyword "â ? ? ? ? ? á à ? ã ? ê ? ? ? ? on desktop

Is useless, because windows is being rubbish at handling those strings - what a surprise, not.

@totaam
Copy link
Collaborator Author

totaam commented Apr 22, 2015

2015-04-22 05:00:20: antoine commented

(this affects 0.15 not 0.14 - updating milestone)

@totaam
Copy link
Collaborator Author

totaam commented Apr 22, 2015

2015-04-22 10:22:45: antoine commented

Testing with a 0.14 server and a patch which I will attach:

  • XP + 0.15 client:
title update, title string=@title@ on @client-machine@
cleaned up title string=@title@ on @client-machine@
metadata_replace atvar=@title@
metadata_replace var=title
metadata_replace default_value=<untitled window>
metadata_replace str value=â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
metadata_replace value=c3a220e1baad20e1baa520e1baa720e1baa920e1baab20c3a120c3a020e1baa120c3a320e1baa320c3aa20e1bb8720e1babf20e1bb8120e1bb83
metadata_replace value=â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
metadata_replace type(â ? ? ? ? ? á à ? ã ? ê ? ? ? ?)=<type 'str'>
metadata_replace=â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
metadata_replace atvar=@client-machine@
metadata_replace var=client-machine
metadata_replace default_value=<unknown machine>
metadata_replace str value=desktop
metadata_replace value=6465736b746f70
metadata_replace value=desktop
metadata_replace type(desktop)=<type 'str'>
metadata_replace=desktop
title after substitution=â ? ? ? ? ? á à ? ã ? ê ? ? ? ? on desktop
utf8_title=â ? ? ? ? ? á à ? ã ? ê ? ? ? ? on desktop
title after substitution=c3a220e1baad20e1baa520e1baa720e1baa920e1baab20c3a120c3a020e1baa120c3a320e1baa320c3aa20e1bb8720e1babf20e1bb8120e1bb83206f6e206465736b746f70
  • XP + 0.14 client:
title update, title string=@title@ on @client-machine@
cleaned up title string=@title@ on @client-machine@
metadata_replace atvar=@title@
metadata_replace var=title
metadata_replace default_value=<untitled window>
metadata_replace type(â ? ? ? ? ? á à ? ã ? ê ? ? ? ?)=<type 'str'>
metadata_replace value=c3a220e1baad20e1baa520e1baa720e1baa920e1baab20c3a120c3a020e1baa120c3a320e1baa320c3aa20e1bb8720e1babf20e1bb8120e1bb83
metadata_replace value=â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
metadata_replace=â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
metadata_replace atvar=@client-machine@
metadata_replace var=client-machine
metadata_replace default_value=<unknown machine>
metadata_replace type(desktop)=<type 'str'>
metadata_replace value=6465736b746f70
metadata_replace value=desktop
metadata_replace=desktop
title after substitution=â ? ? ? ? ? á à ? ã ? ê ? ? ? ? on desktop
utf8_title=â ? ? ? ? ? á à ? ã ? ê ? ? ? ? on desktop
title after substitution=c3a220e1baad20e1baa520e1baa720e1baa920e1baab20c3a120c3a020e1baa120c3a320e1baa320c3aa20e1bb8720e1babf20e1bb8120e1bb83206f6e206465736b746f70
  • win7 + 0.15 client:
title update, title string=@title@ on @client-machine@
cleaned up title string=@title@ on @client-machine@
metadata_replace atvar=@title@
metadata_replace var=title
metadata_replace default_value=<untitled window>
metadata_replace str value=â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
metadata_replace value=c3a220e1baad20e1baa520e1baa720e1baa920e1baab20c3a120c3a020e1baa120c3a320e1baa320c3aa20e1bb8720e1babf20e1bb8120e1bb83
metadata_replace value=â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
metadata_replace type(â ? ? ? ? ? á à ? ã ? ê ? ? ? ?)=<type 'str'>
metadata_replace=â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
metadata_replace atvar=@client-machine@
metadata_replace var=client-machine
metadata_replace default_value=<unknown machine>
metadata_replace str value=desktop
metadata_replace value=6465736b746f70
metadata_replace value=desktop
metadata_replace type(desktop)=<type 'str'>
metadata_replace=desktop
title after substitution=â ? ? ? ? ? á à ? ã ? ê ? ? ? ? on desktop
utf8_title=â ? ? ? ? ? á à ? ã ? ê ? ? ? ? on desktop
title after substitution=c3a220e1baad20e1baa520e1baa720e1baa920e1baab20c3a120c3a020e1baa120c3a320e1baa320c3aa20e1bb8720e1babf20e1bb8120e1bb83206f6e206465736b746f70
  • win7 + 0.14 client:
title update, title string=@title@ on @client-machine@
cleaned up title string=@title@ on @client-machine@
metadata_replace atvar=@title@
metadata_replace var=title
metadata_replace default_value=<untitled window>
metadata_replace type(â ? ? ? ? ? á à ? ã ? ê ? ? ? ?)=<type 'str'>
metadata_replace value=c3a220e1baad20e1baa520e1baa720e1baa920e1baab20c3a120c3a020e1baa120c3a320e1baa320c3aa20e1bb8720e1babf20e1bb8120e1bb83
metadata_replace value=â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
metadata_replace=â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
metadata_replace atvar=@client-machine@
metadata_replace var=client-machine
metadata_replace default_value=<unknown machine>
metadata_replace type(desktop)=<type 'str'>
metadata_replace value=6465736b746f70
metadata_replace value=desktop
metadata_replace=desktop
title after substitution=â ? ? ? ? ? á à ? ã ? ê ? ? ? ? on desktop
utf8_title=â ? ? ? ? ? á à ? ã ? ê ? ? ? ? on desktop
title after substitution=c3a220e1baad20e1baa520e1baa720e1baa920e1baab20c3a120c3a020e1baa120c3a320e1baa320c3aa20e1bb8720e1babf20e1bb8120e1bb83206f6e206465736b746f70

@totaam
Copy link
Collaborator Author

totaam commented Apr 22, 2015

2015-04-22 10:23:19: antoine uploaded file debug-window-title-v2.patch (5.0 KiB)

patch for both branches

@totaam
Copy link
Collaborator Author

totaam commented Apr 23, 2015

2015-04-23 07:31:26: antoine commented

So the "good" news is that XP does the same thing as win7, which makes it easier for me to test. And 0.15 does the same thing as 0.14, the "title after substitution" is the same... And that's bad because it means that something else in the environment is affecting the set_title call.

And then the plot thickens some more: if I connect to an existing session, the utf string is the same and the title is displayed properly initially (at least on win7), but if I change a single character, the update makes it garbled - even if I change it back!? (that's probably why I had created #526)

And finally, on a hunch I tried starting the client with:

XPRA_WIN32_WINDOW_HOOKS=0

And the title displayed properly every time.
So something in those hooks is making GTK unhappy.. and making me unhappy about GTK even more.

r9126 makes it easier to test with the same string everytime (no need for a browser by the way):

./tests/xpra/test_apps/test_window_title.py  "â ậ ấ ầ ẩ ẫ á à ạ ã ả ê ệ ế ề ể ễ ẹ é è ẻ ẽ ô ộ ố ồ ổ ỗ ọ ó ò ỏ õ"

And r9127 allows us to turn off win32 window overrides individually (worth having for the future too). With this change I found that the override that causes the title to get garbled is the MAX_SIZE_HINT one!????
Probably something in the Win32Hooks class, though it looks just fine.

@totaam
Copy link
Collaborator Author

totaam commented Apr 23, 2015

2015-04-23 14:14:57: antoine uploaded file debug-window-title-v3.patch (5.9 KiB)

allows us to try many different ways of setting the title

@totaam
Copy link
Collaborator Author

totaam commented Apr 23, 2015

2015-04-23 14:24:27: antoine commented

The patch above allows us to try 4 different ways of setting the window title, apart from GTK's default implementation which does this:

wtitle = g_utf8_to_utf16 (title, -1, NULL, NULL, NULL);
API_CALL (SetWindowTextW, (GDK_WINDOW_HWND (window), wtitle));

Coupled with the ability to change the character encoding using the env var WM_TEXT_ENCODING and with the ability to choose which hooks we enable (see comment:7). We end up with dozens of combinations... and none of them work.
But I eventually found something interesting: when we enable MAX_SIZE_HINT, the debug output always shows:

user32.IsWindowUnicode=False

Whereas it is True when this is disabled!?
So somehow, we end up disabling unicode support by registering our window handler?!?

Some relevant links:

Weird and frustrating.

@totaam
Copy link
Collaborator Author

totaam commented Apr 23, 2015

2015-04-23 16:10:07: antoine changed status from assigned to new

@totaam
Copy link
Collaborator Author

totaam commented Apr 23, 2015

2015-04-23 16:10:07: antoine changed owner from antoine to John1221

@totaam
Copy link
Collaborator Author

totaam commented Apr 23, 2015

2015-04-23 16:10:07: antoine commented

With r9136, we can disable everything else (the message map is empty, we don't hook the methods on the window class), which confirms that just hooking up the window proc is enough to make it misbehave.

Sounded similar to: Why would Unicode Windows title-bars (only) be question mark (?) code points?.

The strange thing was that we were using the totally standard way of Hooking The Wnd Proc via pywin32's win32gui (examples abound online), and there are no pywin32 wrappers for SetWindowLongW...

But using the ctypes version in r9137 fixes things at last!

@john1221: can you please confirm that the latest beta 0.15 builds for Windows fix the issue for you?
(I will take a look tomorrow at 0.15 servers, since from what you reported there may also be a problem at that end - seems to work for me, but I am on a newer revision than you were, maybe that's the problem - building new rpm and deb packages now)

@totaam
Copy link
Collaborator Author

totaam commented Apr 24, 2015

2015-04-24 03:27:40: John1221 changed owner from John1221 to antoine

@totaam
Copy link
Collaborator Author

totaam commented Apr 24, 2015

2015-04-24 03:27:40: John1221 commented

@antoine: So good!! I tested with r9137 for Windows client, and the issue is fixed.
PS: server-side: Trusty 0.14.22 and 0.15 r9137

@totaam
Copy link
Collaborator Author

totaam commented Apr 24, 2015

2015-04-24 03:31:53: antoine changed status from new to closed

@totaam
Copy link
Collaborator Author

totaam commented Apr 24, 2015

2015-04-24 03:31:53: antoine set resolution to fixed

@totaam
Copy link
Collaborator Author

totaam commented Apr 24, 2015

2015-04-24 03:31:53: antoine commented

@john1221: I can't see any problems with 0.15 servers either. So I am closing this ticket. Feel free to re-open if you have problems with the latest 0.15 beta servers (just posted a new build).

@totaam totaam closed this as completed Apr 24, 2015
@totaam
Copy link
Collaborator Author

totaam commented Apr 24, 2015

2015-04-24 03:45:04: John1221 commented

I've just tested the latest 0.15 beta servers ( trusty) and don't see any problems, too. Thank you for your support. :)

@totaam
Copy link
Collaborator Author

totaam commented Apr 24, 2015

2015-04-24 07:06:34: antoine commented

Well, obviously it was not the end: r9143 was needed to fix the py3k builds which broke as a result of r9137.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@totaam