Problems with Plover keyboard input
159 views
Skip to first unread message
Soren Bjornstad
Aug 19, 2014, 11:22:56 PM8/19/14
to plove...@googlegroups.com
Hi everyone,
I've been playing around with Plover for a few weeks now and think I'm starting to get the hang of steno -- thanks for making this!
Anyway, I'm having some issues with the keyboard emulation. The problems seem to be most noticeable in vim, which is essentially unusable. When I'm in insert mode everything works properly, but in normal mode, some things I type seem to be treated as ordinary keystrokes and some as steno, and it doesn't wait for me to release the keys to do anything. For instance, if I press escape to enter normal mode and then hold down the asterisk key, it begins erasing characters backwards like I tapped the asterisk key -- but I haven't actually completed any keystrokes. (It erases one letter at a time regardless of the number of characters that were entered by each prior stroke, but it's not just tapping 'x' because it's moving backwards.) If I then add, say, 'o', then release both keys, it does correctly go to the next line, but meanwhile part of my file has been randomly erased. This is not a terminal emulator problem as it also happens in gvim; it's also not specifically a vim problem because it also happens in mutt.
Several times now, Plover has also completely stopped working and all keys have been treated as normal regardless of whether the P is green or red; I had to restart Plover to get it to work again.
This one might be a separate issue, but the PLOVER_TOGGLE mapping that I've set up (to SKWRAOEURBGS, if it matters) also behaves somewhat erratically; pressing it with Plover off will stick a bunch of letters into the text field that's currently selected, as expected, but then sometimes when Plover comes back on and catches it it will correctly erase them and sometimes it won't. Worse, it will sometimes erase when there's nothing to erase and wipe out some random characters before the entry.
I'm using the latest Linux version (2.5.8) on Linux Mint with the spectrwm window manager (unusual - possibly an issue?). My system keyboard layout is set to Dvorak, but as long as Plover is started with that layout selected it otherwise works fine (and switching to QWERTY had no effect).
Any help would be greatly appreciated. As it is, I can type in steno under the right circumstances, but I can't really control my computer in any other way (and switching Plover off to do so is also difficult owing to the toggle problem).
I've been playing around with Plover for a few weeks now and think I'm starting to get the hang of steno -- thanks for making this!
Anyway, I'm having some issues with the keyboard emulation. The problems seem to be most noticeable in vim, which is essentially unusable. When I'm in insert mode everything works properly, but in normal mode, some things I type seem to be treated as ordinary keystrokes and some as steno, and it doesn't wait for me to release the keys to do anything. For instance, if I press escape to enter normal mode and then hold down the asterisk key, it begins erasing characters backwards like I tapped the asterisk key -- but I haven't actually completed any keystrokes. (It erases one letter at a time regardless of the number of characters that were entered by each prior stroke, but it's not just tapping 'x' because it's moving backwards.) If I then add, say, 'o', then release both keys, it does correctly go to the next line, but meanwhile part of my file has been randomly erased. This is not a terminal emulator problem as it also happens in gvim; it's also not specifically a vim problem because it also happens in mutt.
Several times now, Plover has also completely stopped working and all keys have been treated as normal regardless of whether the P is green or red; I had to restart Plover to get it to work again.
This one might be a separate issue, but the PLOVER_TOGGLE mapping that I've set up (to SKWRAOEURBGS, if it matters) also behaves somewhat erratically; pressing it with Plover off will stick a bunch of letters into the text field that's currently selected, as expected, but then sometimes when Plover comes back on and catches it it will correctly erase them and sometimes it won't. Worse, it will sometimes erase when there's nothing to erase and wipe out some random characters before the entry.
I'm using the latest Linux version (2.5.8) on Linux Mint with the spectrwm window manager (unusual - possibly an issue?). My system keyboard layout is set to Dvorak, but as long as Plover is started with that layout selected it otherwise works fine (and switching to QWERTY had no effect).
Any help would be greatly appreciated. As it is, I can type in steno under the right circumstances, but I can't really control my computer in any other way (and switching Plover off to do so is also difficult owing to the toggle problem).
Benoit Pierre
Aug 20, 2014, 7:57:43 AM8/20/14
to plove...@googlegroups.com
On Wed, Aug 20, 2014 at 5:22 AM, Soren Bjornstad
<soren.b...@gmail.com> wrote:
> Hi everyone,
Hi,
> I've been playing around with Plover for a few weeks now and think I'm
> starting to get the hang of steno -- thanks for making this!
>
> Anyway, I'm having some issues with the keyboard emulation. The problems
> seem to be most noticeable in vim, which is essentially unusable. When I'm
> in insert mode everything works properly, but in normal mode, some things I
> type seem to be treated as ordinary keystrokes and some as steno, and it
> doesn't wait for me to release the keys to do anything. For instance, if I
> press escape to enter normal mode and then hold down the asterisk key, it
> begins erasing characters backwards like I tapped the asterisk key -- but I
> haven't actually completed any keystrokes. (It erases one letter at a time
> regardless of the number of characters that were entered by each prior
> stroke, but it's not just tapping 'x' because it's moving backwards.) If I
> then add, say, 'o', then release both keys, it does correctly go to the next
> line, but meanwhile part of my file has been randomly erased. This is not a
> terminal emulator problem as it also happens in gvim; it's also not
> specifically a vim problem because it also happens in mutt.
This is due to the way Plover works on Linux: the keyboard is not
really suppressed (as in grabbed) when Plover is on, so what happens
is:
- you press and hold the 'a' key: the application receives and process the event
- Plover 'suppress' the key by sending a backspace
- this happens a number of times (due to key repeat) until you release the key
- Plover then send the steno translation S -> is
Unfortunately, this method of 'suppressing' a key event by sending a
backspace event only work if the application has not already processed
the key: like in a text field, or when VIM is in input mode.
You can try this modified version of Plover:
https://github.com/benoit-pierre/plover/tree/bpierre
The steno keys will be grabbed when Plover is active, so the
application will never see those intermediate key events, but only the
final translation sent by Plover.
Note however, that this does not resolve the problem of the
PLOVER_TOGGLE mapping, when switching Plover on: this will never works
completely, as you won't always be able to undo the sequence of key
events that correspond to the stroke you mapped in your dictionary.
> Several times now, Plover has also completely stopped working and all keys
> have been treated as normal regardless of whether the P is green or red; I
> had to restart Plover to get it to work again.
This is not normal, did you check the log for clues?
> This one might be a separate issue, but the PLOVER_TOGGLE mapping that I've
> set up (to SKWRAOEURBGS, if it matters) also behaves somewhat erratically;
> pressing it with Plover off will stick a bunch of letters into the text
> field that's currently selected, as expected, but then sometimes when Plover
> comes back on and catches it it will correctly erase them and sometimes it
> won't. Worse, it will sometimes erase when there's nothing to erase and wipe
> out some random characters before the entry.
See above.
> I'm using the latest Linux version (2.5.8) on Linux Mint with the spectrwm
> window manager (unusual - possibly an issue?). My system keyboard layout is
> set to Dvorak, but as long as Plover is started with that layout selected it
> otherwise works fine (and switching to QWERTY had no effect).
>
> Any help would be greatly appreciated. As it is, I can type in steno under
> the right circumstances, but I can't really control my computer in any other
> way (and switching Plover off to do so is also difficult owing to the toggle
> problem).
Cheers,
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
<soren.b...@gmail.com> wrote:
> Hi everyone,
Hi,
> I've been playing around with Plover for a few weeks now and think I'm
> starting to get the hang of steno -- thanks for making this!
>
> Anyway, I'm having some issues with the keyboard emulation. The problems
> seem to be most noticeable in vim, which is essentially unusable. When I'm
> in insert mode everything works properly, but in normal mode, some things I
> type seem to be treated as ordinary keystrokes and some as steno, and it
> doesn't wait for me to release the keys to do anything. For instance, if I
> press escape to enter normal mode and then hold down the asterisk key, it
> begins erasing characters backwards like I tapped the asterisk key -- but I
> haven't actually completed any keystrokes. (It erases one letter at a time
> regardless of the number of characters that were entered by each prior
> stroke, but it's not just tapping 'x' because it's moving backwards.) If I
> then add, say, 'o', then release both keys, it does correctly go to the next
> line, but meanwhile part of my file has been randomly erased. This is not a
> terminal emulator problem as it also happens in gvim; it's also not
> specifically a vim problem because it also happens in mutt.
really suppressed (as in grabbed) when Plover is on, so what happens
is:
- you press and hold the 'a' key: the application receives and process the event
- Plover 'suppress' the key by sending a backspace
- this happens a number of times (due to key repeat) until you release the key
- Plover then send the steno translation S -> is
Unfortunately, this method of 'suppressing' a key event by sending a
backspace event only work if the application has not already processed
the key: like in a text field, or when VIM is in input mode.
You can try this modified version of Plover:
https://github.com/benoit-pierre/plover/tree/bpierre
The steno keys will be grabbed when Plover is active, so the
application will never see those intermediate key events, but only the
final translation sent by Plover.
Note however, that this does not resolve the problem of the
PLOVER_TOGGLE mapping, when switching Plover on: this will never works
completely, as you won't always be able to undo the sequence of key
events that correspond to the stroke you mapped in your dictionary.
> Several times now, Plover has also completely stopped working and all keys
> have been treated as normal regardless of whether the P is green or red; I
> had to restart Plover to get it to work again.
> This one might be a separate issue, but the PLOVER_TOGGLE mapping that I've
> set up (to SKWRAOEURBGS, if it matters) also behaves somewhat erratically;
> pressing it with Plover off will stick a bunch of letters into the text
> field that's currently selected, as expected, but then sometimes when Plover
> comes back on and catches it it will correctly erase them and sometimes it
> won't. Worse, it will sometimes erase when there's nothing to erase and wipe
> out some random characters before the entry.
> I'm using the latest Linux version (2.5.8) on Linux Mint with the spectrwm
> window manager (unusual - possibly an issue?). My system keyboard layout is
> set to Dvorak, but as long as Plover is started with that layout selected it
> otherwise works fine (and switching to QWERTY had no effect).
>
> Any help would be greatly appreciated. As it is, I can type in steno under
> the right circumstances, but I can't really control my computer in any other
> way (and switching Plover off to do so is also difficult owing to the toggle
> problem).
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
Soren Bjornstad
Aug 20, 2014, 8:50:12 AM8/20/14
to plove...@googlegroups.com
On 08/20, Benoit Pierre wrote:
> You can try this modified version of Plover:
> https://github.com/benoit-pierre/plover/tree/bpierre
Doesn't seem to be any different.
> You can try this modified version of Plover:
> https://github.com/benoit-pierre/plover/tree/bpierre
I thought remapping backspace to nothing might help, but oddly that
doesn't seem to have changed anything at all -- does Plover use some
different key to backspace?
> > Several times now, Plover has also completely stopped working and all keys
> > have been treated as normal regardless of whether the P is green or red; I
> > had to restart Plover to get it to work again.
>
> This is not normal, did you check the log for clues?
happens again I'll make sure to check right away to be sure I catch it,
and I'll let you know if there's anything interesting there.
Benoit Pierre
Aug 20, 2014, 9:11:53 AM8/20/14
to plove...@googlegroups.com
On Wed, Aug 20, 2014 at 2:50 PM, Soren Bjornstad
<soren.b...@gmail.com> wrote:
> On 08/20, Benoit Pierre wrote:
>> You can try this modified version of Plover:
>> https://github.com/benoit-pierre/plover/tree/bpierre
>
> Doesn't seem to be any different.
That's weird. Just to clarify: you're using gvim? What exact sequence
<soren.b...@gmail.com> wrote:
> On 08/20, Benoit Pierre wrote:
>> You can try this modified version of Plover:
>> https://github.com/benoit-pierre/plover/tree/bpierre
>
> Doesn't seem to be any different.
of steno keys do you test with? Can you check what happens with xev?
Normally, with Plover standard version, you'll see all those
intermediate keypress, but not with my version. Note that Plover will
still need to send backspace events when it needs to correct a word:
for erasing with *, or e.g. for cases like this:
- SKEL -> cancel
- SKEL TOPB -> skeleton
> I thought remapping backspace to nothing might help, but oddly that
> doesn't seem to have changed anything at all -- does Plover use some
> different key to backspace?
Backspace is mapped on (so according to your X11 keyboard layout).
Soren Bjornstad
Aug 20, 2014, 9:55:35 AM8/20/14
to plove...@googlegroups.com
On 08/20, Benoit Pierre wrote:
> That's weird. Just to clarify: you're using gvim? What exact sequence
> of steno keys do you test with? Can you check what happens with xev?
> Normally, with Plover standard version, you'll see all those
> intermediate keypress, but not with my version.
I started vim, turned on Plover, and entered *EU TO TKPWO THR-, then
> That's weird. Just to clarify: you're using gvim? What exact sequence
> of steno keys do you test with? Can you check what happens with xev?
> Normally, with Plover standard version, you'll see all those
> intermediate keypress, but not with my version.
pressed Esc and held down the * key.
I initially tested it in terminal vim, which is what I normally use, but
terminal or gvim makes no difference.
xev seems to be showing alternate presses and releases of *both* the 'd'
key ('h' QWERTY position, so the same key I'm pressing) and the
backspace key. Here's a small snippet of what happens when I hold it
down:
KeyRelease event, serial 42, synthetic YES, window 0x3c00001,
root 0xbe, subw 0x0, time 8056, (1,1), root:(1,1),
state 0x0, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
XLookupString gives 1 bytes: (08) "
XFilterEvent returns: False
KeyPress event, serial 42, synthetic YES, window 0x3c00001,
root 0xbe, subw 0x0, time 8057, (1,1), root:(1,1),
state 0x0, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
XLookupString gives 1 bytes: (08) "
XmbLookupString gives 1 bytes: (08) "
XFilterEvent returns: False
KeyRelease event, serial 42, synthetic NO, window 0x3c00001,
root 0xbe, subw 0x0, time 756147290, (104,55), root:(2406,733),
state 0x10, keycode 43 (keysym 0x64, d), same_screen YES,
XLookupString gives 1 bytes: (64) "d"
XFilterEvent returns: False
KeyPress event, serial 42, synthetic NO, window 0x3c00001,
root 0xbe, subw 0x0, time 756147290, (104,55), root:(2406,733),
state 0x10, keycode 43 (keysym 0x64, d), same_screen YES,
XLookupString gives 1 bytes: (64) "d"
XmbLookupString gives 1 bytes: (64) "d"
XFilterEvent returns: False
KeyRelease event, serial 42, synthetic YES, window 0x3c00001,
root 0xbe, subw 0x0, time 8058, (1,1), root:(1,1),
state 0x0, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
XLookupString gives 1 bytes: (08) "
XFilterEvent returns: False
KeyPress event, serial 42, synthetic YES, window 0x3c00001,
root 0xbe, subw 0x0, time 8059, (1,1), root:(1,1),
state 0x0, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
XLookupString gives 1 bytes: (08) "
XmbLookupString gives 1 bytes: (08) "
XFilterEvent returns: False
KeyRelease event, serial 42, synthetic NO, window 0x3c00001,
root 0xbe, subw 0x0, time 756147301, (104,55), root:(2406,733),
state 0x10, keycode 43 (keysym 0x64, d), same_screen YES,
XLookupString gives 1 bytes: (64) "d"
XFilterEvent returns: False
I'm using a Sidewinder keyboard, by the way.
> Note that Plover will
> still need to send backspace events when it needs to correct a word:
> for erasing with *, or e.g. for cases like this:
The one other thing I thought of is that perhaps the new Plover version
didn't install properly over the old one (I don't see anything in the
About dialog that specifies it's different), but I ran sudo python
setup.py install and it completed with no errors.
If it's helpful, here's vim --version:
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jan 2 2014 19:39:59)
Included patches: 1-52
Modified by pkg-vim-m...@lists.alioth.debian.org
Compiled by buildd@
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl +farsi +mouse_netterm +syntax
+arabic +file_in_path +mouse_sgr +tag_binary
+autocmd +find_in_path -mouse_sysmouse +tag_old_static
+balloon_eval +float +mouse_urxvt -tag_any_white
+browse +folding +mouse_xterm +tcl
++builtin_terms -footer +multi_byte +terminfo
+byte_offset +fork() +multi_lang +termresponse
+cindent +gettext -mzscheme +textobjects
+clientserver -hangul_input +netbeans_intg +title
+clipboard +iconv +path_extra +toolbar
+cmdline_compl +insert_expand +perl +user_commands
+cmdline_hist +jumplist +persistent_undo +vertsplit
+cmdline_info +keymap +postscript +virtualedit
+comments +langmap +printer +visual
+conceal +libcall +profile +visualextra
+cryptv +linebreak +python +viminfo
+cscope +lispindent -python3 +vreplace
+cursorbind +listcmds +quickfix +wildignore
+cursorshape +localmap +reltime +wildmenu
+dialog_con_gui +lua +rightleft +windows
+diff +menu +ruby +writebackup
+digraphs +mksession +scrollbind +X11
+dnd +modify_fname +signs -xfontset
-ebcdic +mouse +smartindent +xim
+emacs_tags +mouseshape -sniff +xsmp_interact
+eval +mouse_dec +startuptime +xterm_clipboard
+ex_extra +mouse_gpm +statusline -xterm_save
+extra_search -mouse_jsbterm -sun_workshop +xpm
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/harfbuzz -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -I/usr/include/tcl8.6 -D_REENTRANT=1 -D_THREAD_SAFE=1 -D_LARGEFILE64_SOURCE=1
Linking: gcc -L. -Wl,-Bsymbolic-functions -Wl,-z,relro -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lnsl -lselinux -lacl -lattr -lgpm -ldl -L/usr/lib -llua5.2 -Wl,-E -fstack-protector -L/usr/local/lib -L/usr/lib/perl/5.18/CORE -lperl -ldl -lm -lpthread -lcrypt -L/usr/lib/python2.7/config-x86_64-linux-gnu -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -ldl -lz -lpthread -lieee -lm -lruby-1.9.1 -lpthread -lrt -ldl -lcrypt -lm -L/usr/lib
Benoit Pierre
Aug 20, 2014, 10:20:59 AM8/20/14
to plove...@googlegroups.com
It's not the default branch, so you need to clone with a command like
this:
git clone --single-branch --branch bpierre
https://github.com/benoit-pierre/plover.git
or switch to the branch after a regular clone: git checkout bpierre
>> Note that Plover will
>> still need to send backspace events when it needs to correct a word:
>> for erasing with *, or e.g. for cases like this:
>
> Right, that makes sense and shouldn't be a problem.
>
> The one other thing I thought of is that perhaps the new Plover version
> didn't install properly over the old one (I don't see anything in the
> About dialog that specifies it's different), but I ran sudo python
> setup.py install and it completed with no errors.
python2 -c 'from plover.oslayer.xkeyboardcontrol import
KeyboardCapture; print KeyboardCapture().can_suppress_keyboard()'
Soren Bjornstad
Aug 20, 2014, 11:11:51 AM8/20/14
to plove...@googlegroups.com
On 08/20, Benoit Pierre wrote:
> Looks like the regular version of Plover. How did you clone my branch?
> It's not the default branch, so you need to clone with a command like
> this:
>
> git clone --single-branch --branch bpierre
> https://github.com/benoit-pierre/plover.git
Aha, I missed that part. Now it's working *differently*, but still not
> Looks like the regular version of Plover. How did you clone my branch?
> It's not the default branch, so you need to clone with a command like
> this:
>
> git clone --single-branch --branch bpierre
> https://github.com/benoit-pierre/plover.git
correctly: it's now not suppressing the normal keyboard entries at all,
so it repeatedly enters the character at that position until the keys
are let up, then enters the result of the steno keypress. So xev looks
something like this when I key T- (Dvorak , at that position):
KeyPress event, serial 40, synthetic NO, window 0x4000001,
root 0xbe, subw 0x0, time 757188238, (161,159), root:(2463,842),
state 0x10, keycode 25 (keysym 0x2c, comma), same_screen YES,
XLookupString gives 1 bytes: (2c) ","
XmbLookupString gives 1 bytes: (2c) ","
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x4000001,
root 0xbe, subw 0x0, time 757188278, (161,159), root:(2463,842),
state 0x10, keycode 25 (keysym 0x2c, comma), same_screen YES,
XLookupString gives 1 bytes: (2c) ","
XFilterEvent returns: False
KeyPress event, serial 40, synthetic NO, window 0x4000001,
root 0xbe, subw 0x0, time 757188278, (161,159), root:(2463,842),
state 0x10, keycode 25 (keysym 0x2c, comma), same_screen YES,
XLookupString gives 1 bytes: (2c) ","
XmbLookupString gives 1 bytes: (2c) ","
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x4000001,
root 0xbe, subw 0x0, time 757188309, (161,159), root:(2463,842),
state 0x10, keycode 25 (keysym 0x2c, comma), same_screen YES,
XLookupString gives 1 bytes: (2c) ","
XFilterEvent returns: False
KeyPress event, serial 40, synthetic YES, window 0x4000001,
root 0xbe, subw 0x0, time 323, (1,1), root:(1,1),
state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
XLookupString gives 1 bytes: (20) " "
XmbLookupString gives 1 bytes: (20) " "
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic YES, window 0x4000001,
root 0xbe, subw 0x0, time 324, (1,1), root:(1,1),
state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
XLookupString gives 1 bytes: (20) " "
XFilterEvent returns: False
KeyPress event, serial 40, synthetic YES, window 0x4000001,
root 0xbe, subw 0x0, time 325, (1,1), root:(1,1),
state 0x0, keycode 42 (keysym 0x69, i), same_screen YES,
XLookupString gives 1 bytes: (69) "i"
XmbLookupString gives 1 bytes: (69) "i"
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic YES, window 0x4000001,
root 0xbe, subw 0x0, time 326, (1,1), root:(1,1),
state 0x0, keycode 42 (keysym 0x69, i), same_screen YES,
XLookupString gives 1 bytes: (69) "i"
XFilterEvent returns: False
KeyPress event, serial 40, synthetic YES, window 0x4000001,
root 0xbe, subw 0x0, time 327, (1,1), root:(1,1),
state 0x0, keycode 45 (keysym 0x74, t), same_screen YES,
XLookupString gives 1 bytes: (74) "t"
XmbLookupString gives 1 bytes: (74) "t"
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic YES, window 0x4000001,
root 0xbe, subw 0x0, time 328, (1,1), root:(1,1),
state 0x0, keycode 45 (keysym 0x74, t), same_screen YES,
XLookupString gives 1 bytes: (74) "t"
XFilterEvent returns: False
This happens in all programs, not just ones that weren't working before.
Is there maybe some system setting that's causing the issue?
> The following command line should show 'True' if you're using the right version:
>
> python2 -c 'from plover.oslayer.xkeyboardcontrol import
> KeyboardCapture; print KeyboardCapture().can_suppress_keyboard()'
cloning this time.)
Thanks for your help, by the way!
Benoit Pierre
Aug 20, 2014, 12:18:03 PM8/20/14
to plove...@googlegroups.com
On Wed, Aug 20, 2014 at 5:11 PM, Soren Bjornstad
<soren.b...@gmail.com> wrote:
>
>
> [...]
So the grabs are not working... Can you try the attached test script?
It should grab the left homerow (so qwerty 'asdf', dvorak 'aoeu').
<soren.b...@gmail.com> wrote:
>
>
> [...]
It should grab the left homerow (so qwerty 'asdf', dvorak 'aoeu').
Soren Bjornstad
Aug 20, 2014, 12:44:31 PM8/20/14
to plove...@googlegroups.com
On 08/20, Benoit Pierre wrote:
> So the grabs are not working... Can you try the attached test script?
> It should grab the left homerow (so qwerty 'asdf', dvorak 'aoeu').
On running, it returns:
> It should grab the left homerow (so qwerty 'asdf', dvorak 'aoeu').
<class 'Xlib.protocol.request.QueryExtension'>
None
None
None
None
xev does show 38, 39, 40, and 41 keycodes for those four keys.
I should note that I have my internal laptop keyboard, my steno board,
and another keyboard hooked up at the same time. Unplugging all
keyboards except the internal one didn't change anything.
If I press a key on one of the keyboards while the script is running, I
get the output:
<class 'Xlib.protocol.event.MappingNotify'>(count = 248, request = 1,
first_keycode = 8, type = 34, sequence_number = 12)
<class 'Xlib.protocol.event.MappingNotify'>(count = 0, request = 0,
first_keycode = 0, type = 34, sequence_number = 12)
I'm assuming this is an event for switching keyboards, as I can't make
it happen again by pressing a key on that keyboard until I've first
pressed a key on a different keyboard. The output is always exactly the
same regardless of what keyboard I press a key on.
If I activate Plover while the script is running, it prints:
X protocol error:
<class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 344, major_opcode = 33, minor_opcode = 0
X protocol error:
<class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 345, major_opcode = 33, minor_opcode = 0
X protocol error:
<class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 346, major_opcode = 33, minor_opcode = 0
X protocol error:
<class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 347, major_opcode = 33, minor_opcode = 0
Benoit Pierre
Aug 20, 2014, 1:02:51 PM8/20/14
to plove...@googlegroups.com
Anyway, I may have an idea as to why it's not working for you, do you
have numlock activated? If it is, can you try without it?
All my keyboards are tenkeyless, so I deactivate numlock, but if I
enable it with 'numlockx on', then the grabs don't work, because I
asked for a grab with no modifiers.
Benoit Pierre
Aug 20, 2014, 1:25:50 PM8/20/14
to plove...@googlegroups.com
On Wed, Aug 20, 2014 at 7:02 PM, Benoit Pierre <benoit...@gmail.com> wrote:
>
> [...]
clearly numlock is on. I pushed an updated version with a fix on
GitHub.
>
> [...]
>
>> If I activate Plover while the script is running, it prints:
>> X protocol error:
>> <class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 344, major_opcode = 33, minor_opcode = 0
>> X protocol error:
>> <class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 345, major_opcode = 33, minor_opcode = 0
>> X protocol error:
>> <class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 346, major_opcode = 33, minor_opcode = 0
>> X protocol error:
>> <class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 347, major_opcode = 33, minor_opcode = 0
>
> This is normal: Plover cannot grabs the already grabbed keys.
>
> Anyway, I may have an idea as to why it's not working for you, do you
> have numlock activated? If it is, can you try without it?
>
> All my keyboards are tenkeyless, so I deactivate numlock, but if I
> enable it with 'numlockx on', then the grabs don't work, because I
> asked for a grab with no modifiers.
Looking back at your earlier xev traces, I see that: state 0x10, so
>> If I activate Plover while the script is running, it prints:
>> X protocol error:
>> <class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 344, major_opcode = 33, minor_opcode = 0
>> X protocol error:
>> <class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 345, major_opcode = 33, minor_opcode = 0
>> X protocol error:
>> <class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 346, major_opcode = 33, minor_opcode = 0
>> X protocol error:
>> <class 'Xlib.error.BadAccess'>: code = 10, resource_id = 190, sequence_number = 347, major_opcode = 33, minor_opcode = 0
>
> This is normal: Plover cannot grabs the already grabbed keys.
>
> Anyway, I may have an idea as to why it's not working for you, do you
> have numlock activated? If it is, can you try without it?
>
> All my keyboards are tenkeyless, so I deactivate numlock, but if I
> enable it with 'numlockx on', then the grabs don't work, because I
> asked for a grab with no modifiers.
clearly numlock is on. I pushed an updated version with a fix on
GitHub.
Soren Bjornstad
Aug 20, 2014, 2:07:15 PM8/20/14
to plove...@googlegroups.com
The new version fixes it. Thanks for all the help, and keep up the great
work with Plover!
Soren
On 08/20, Benoit Pierre wrote:
> --
> You received this message because you are subscribed to a topic in the Google Groups "Plover" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/ploversteno/RKpkNL2CMfs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to ploversteno...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
work with Plover!
Soren
On 08/20, Benoit Pierre wrote:
> You received this message because you are subscribed to a topic in the Google Groups "Plover" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/ploversteno/RKpkNL2CMfs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to ploversteno...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages