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

[Jakub Księżniak]

Hi,

Of course, I'm willing to share the code and I thought about publishing it
on GitHub, but it's quite a mess now. I'll try to clean up it soon, or I
can PM you earlier if you want.

Regarding 'transient-for' hint, I've got difficulties to run xprop and open
menus at the same time. :) The program I run is 'konsole' from KDE, but
also Gimp and other apps have this issue.

-- 
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
>