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