Hello
Some applications like games, virtual machines may require programs to the graphics capabilities capture the mouse (Mouse grab). Xpra from version to version is getting better software for remote operation, so I think that this option should be added.
That's already the case as of r12645 (trunk), see ticket:1195#comment:1 for details.
Please close if that works for you.
@antoine Don't know how (?)
Right Control does not capture the mouse or keyboard. Or maybe I don't understand this function
Perhaps the feature does not work (other shortcuts like Alt + Shift + F2 function)
@fervi:
@antoine
Xpra was installed with the package; version 0.18.1 (17-Jun-2016 08:57) It is true that it comes from the repository winswitch http://winswitch.org/beta/
But checksum packet agrees with the sum of control repository xpra (beta).
In xpra --help is the shortcut key.
--key-shortcut = KEY_SHORTCUT Define key shortcuts That will trigger specific actions.If no shortcuts are defined, it defaults to: Control_R: toggle_keyboard_grab
Maybe xpra must work in the "shadow" and not "multiple windows"? Or it may not work with qemu.
If, of course, you can check with each other; try and work with qemu-system-i386.
Surely this option allows you to capture mouse?
What platform?
Please try running with -d keyboard
and post the output.
FYI: xpra and winswitch repositories are identical (symlinked).
@antoine
https://www.youtube.com/watch?v=SBZDwlzOMWY&feature=youtu.be no ctrl - Control button is not pressed ctrl - Control button was pressed (several times for tests)
http://gmclan.org/uploader/6184/keyboard.txt
Server and my computer have newest Xpra version; I have Debian Stretch (Devuan Ascii), Server - Debian Jessie
Milestone renamed
Duplicate of #139? fervi appears to be talk about mouse grab, antoine appears to be talking about keyboard grab.
Done in for pointer grabs in r13144. Use the "Menu" key to toggle pointer grabs. We confine the pointer to the window which had focus. We could also do an unconfined pointer grab if needed. (would require yet another key shortcut)
This is almost identical to #1195 but for grabbing the pointer instead of keyboard.
Important: the shortcuts have just been changed, see r13169
Replying to antoine's ticket:139#comment:37:
Ran with ...
Should be something like (paths may vary):PYTHONPATH=~/xpra/lib64/python/ ~/xpra/bin/xpra ...Otherwise you will be using the system installed version.
(See ticket:139#comment:36) I verified in two different ways that the local build was running, both in the console and in the tray application's "About" menu.
PYTHONPATH
was exported in my environment.
With grab logging, no events are logged when I press the Menu or Control_R keys.
Please attach the client output with-d keyboard,grab
. We want to verify the keyboard shortcuts are parsed correctly and that they are caught as well.
Will attempt again this evening with -d keyboard,grab
. How do you want me to report my results? Attachment or inline? I imagine there will be a fair amount of output.
Replying to antoine's ticket:139#comment:38:
Important: the shortcuts have just been changed, see r13169
Noted; I'll checkout and build r13169.
Derp, fixing assign; meant to do that for #139, not this ticket.
Attachment or inline?
Small: inline, big: attachment. Where small is roughly less than a page.
Bump! (new beta builds posted)
Not heard back.
@afarr: just a FYI, feel free to close. (see comment:10, the "Shift+Menu" key shortcut toggles pointer confinement)
Still nothing. SUPER + Shift and Right_Control - not change anything
@fervi: no debug info... so not likely to change since this is tested and working here.
Well, for what it's worth, I took a stab with 1.0 r13888 windows client against 1.0 r13912 fedora 23 server.
Control-R seems to trigger a (reverse-i-search)`'
.
Meanwhile, Control_R (the right control button) seems to be recognized by the gtk_view_keyboard.py
tool, but doesn't seem to allow me to do anything obvious in something like an xterm (nothing is outputted, no sign of any effect, pressing that key).
The keyboard tool recognizes it as follows:
down Control_R 65508 109 1 0 ['2'] up Control_R 65508 109 1 0 ['2', 'C']
The "Menu" key, meanwhile, outputs a '~' when typed into an xterm, but doesn't seem to have any other effect. In the keyboard tool, it outputs:
down Menu 65383 117 0 0 ['2'] up Menu 65383 117 0 0 ['2']
Just in case it seems relevant, the "Super" key (windows icon thing, from what I've managed to read) outputs this on the keyboard tool.
down Alt_L 65513 64 1 0 ['2'] up Alt_L 65513 64 1 0 ['2, '1']
Likewise, trying to use Control_R + Super, I see the following, (mostly) exactly as expected:
down Control_R 65508 109 1 0 ['2'] down Alt_L 65513 64 1 0 ['2', 'C'] up Alt_L 65513 64 1 0 ['2', 'C', '1'] up Control_R 65508 109 1 0 ['2', 'C']
Since SUPER + Shit is mentioned in the above comment... well, keyboard tool gives me the following for shift (left shift) + SUPER:
down Shift_L 65505 50 1 0 ['2'] down Meta_L 65511 64 1 0 ['2', 'S'] up Meta_L 65511 64 1 0 ['2', 'S', '1'] up Shift_L 65505 50 1 0 ['2', 'S']
Let me know if any more keyboard tests are needed.
Turns out that GTK does not support pointer grabs at all on win32, so I've added support for it using ClipCursor via pywin32 in r13923. (behaviour is unlikely to be 100% identical to X11 clients). Keyboard grabs are not handled by GTK either, we already have pywin32 custom code for that too (see #1152 for details). OSX: not supported by GTK since this is not supported by the os: #1326
Summary of what this feature does for testing purposes:
Tested with r13937 Windows 8.1 Client and a Fedora 23 r13941 trunk Client against a Fedora 23 r13941 trunk server:
However there are a couple caveats:
Passing back to you.
@maxmylyn: is this specific to win 8.1 or does this occur with all version of windows? please include the "-d grab" log output and attach the output of "Native_gui.exe".
The problem is likely to be because of http://stackoverflow.com/a/34143777/428751: Windows 10 has thin invisible borders..
r14095 now uses SM_CYCAPTION
(GetSystemMetrics) if the window has a caption. Maybe this will work better already? (r14096 will also log the vista-onwards-only DWMWA_EXTENDED_FRAME_BOUNDS
)
Hopefully we can calculate the correct inner window dimensions.
Works fine for me on XP and win7: tested with a simple xterm or xev, all the events land in the window, I cannot resize of move it whilst the grab is active.
I don't understand the "re-center" issue at all, can you include a screenshot?
Upped server to r14271 (now Fedora 24), and client to r14228:
Since both issues I found have been fixed, and I can't induce any more, I'm gonna go ahead and close this ticket (finally).
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1229