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

Jakub Księżniak jksiezniak at gmail.com
Thu May 14 22:06:01 BST 2015

2015-05-13 11:53 GMT+02:00 Antoine Martin <antoine at nagafix.co.uk>:

>  "Release early, release often"... something we have somewhat failed to do
> lately.
> But if I post it, others may be able to help.
So, I've just published on GitHub the code I've written so far. As a
reminder, only a Swing client is working now.

The repo depends on submodules, so it should be cloned with --recursive
$ git clone --recursive https://github.com/jksiezni/xpra-client.git

I've been reading about X11 keyboard management and I haven't found an easy
(and cross-platform) way to translate Java keycodes to what Xpra requires.
Thus, I'm switching to Android hoping to find an easier way in providing
key-mappings to Xpra.

Jakub Księżniak

> --
>  Regards,
>  Jakub Księżniak
> 2015-05-12 6:56 GMT+02:00 Antoine Martin <antoine at nagafix.co.uk>:
>> 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.
>>  Excellent!
>> 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.
>> Cheers
>> Antoine
>> _______________________________________________
>> shifter-users mailing list
>> shifter-users at lists.devloop.org.uk
>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users

More information about the shifter-users mailing list