2015-05-13 11:53 GMT+02:00 Antoine Martin <[email protected]>: > > "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. https://github.com/jksiezni/xpra-client
The repo depends on submodules, so it should be cloned with --recursive parameter: $ 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. Regards, Jakub Księżniak > > > > -- > Regards, > Jakub Księżniak > > 2015-05-12 6:56 GMT+02:00 Antoine Martin <[email protected]>: > >> 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 >> [email protected] >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > > > _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
