[winswitch] [xpra] Implementation of Java/Android client

Antoine Martin antoine at nagafix.co.uk
Tue May 12 05:56:18 BST 2015

On 12/05/15 00:52, Jakub Księżniak wrote:
> Hello devs,
> I've started writing a new Java/Android client. Currently, I'm developing a
> Swing client as a Proof of Concept and I think, that it has already
> surpassed the old java client found in SVN repo, as it supports both
> bencode and rencode packet encodings, fully controls life-cycle of windows
> and popups (create, move, resize, etc.) and handles all mouse events.
Can you share the code so we can try it?
> However, it still lacks keyboard support and I'd like to ask you for help
> and explanation, how key mapping works? (If that's not possible then I'll
> try to figure out it on my own. :-))
Good question.. but there is no easy answer I am afraid.
The key mapping code is a mixture of GTK and X11 key definitions 
(because that's how the code started), with lots of hacks to get other 
platforms to work more or less properly...
> In the old java client there is a code that builds key-mappings and appends
> them to 'hello' packet. Each KeySpec consists of a keyval, keyname,
> keycode, group and level. Then, on 'key-action' event, there is sent
> keyval, keyname and keycode again. It looks like some redundant data is
> sent here, so I'd like to simplify it a bit, but first I need to understand
> what design decisions are behind this key-mapping logic. :p
Mostly: backwards compatibility.
They are not as redundant as you might think. The same keycode can emit 
multiple keysyms.
I would focus on getting the basics working with your new client rather 
than trying to refactor some code which is very tricky to get right for 
all platforms.
(unless you have time to test all the platforms with all the layouts - 
we're talking many weeks of testing here...)
> Also, I've noticed some issues with my Xpra installation (v0.14.22):
> 1. Initial window positioning constantly changes.
> a) $ xpra start :100 --start-child=xterm
> b) Connect with 'xpra attach' to the server and move the window to the top
> left corner.
> c) Disconnect and connect repeatedly and notice how the window is moved a
> bit down on each connection. (I'm using KDE environment, if it helps.)
That's a known issue with the window frame moving the actual window 
contents a bit.
Not a huge issue IMO.
> 2. When a menu is opened, the Xpra server provides a 'transient-for' value
> which helps to associate with a parent window, but when a sub-menu is
> opened the 'transient-for' is missing. Is it a correct behaviour?
Which application are you testing with?
The transient-for hint is supplied (or not) by client applications and 
xpra just forwards it to the client.
Unfortunately, many applications and toolkits do not always provide this 
useful window management hint.
You can verify it server-side with xprop.


More information about the shifter-users mailing list