"Sticky" Metakeys

[stenoknight]

Currently metakey combinations can be defined in the Plover dictionary as a cluster -- e.g., "TA*BT": "{#Alt_L(Tab)}", for "hold down alt and then press tab". But this poses a few problems. First of all, it means that Plover can't do metakey combinations on the fly; if you want to do Control-f in the dictionary but you don't have it specifically defined, writing your stroke for {#Control_L} and then your stroke for {&f} won't have the desired effect. Plover should be able to allow for a "sticky" stroke, which will keep Control, Alt, Shift, et cetera, in the buffer without executing it, and apply it to the translation of the next stroke. If the next stroke is also a meta key, Plover should add that to the stack, so that multiple metakeys can be employed on the fly.

[samlh]

What should the syntax for marking a combination as sticky be?

One option would be to detect unclosed parenthesis, and pull in the next keystroke. Thus, {#Control_L(}{#Shift_L(}{#Tab} would be equivalent to {#Control_L(Shift_L(Tab))}. This could even be extended to {#Alt_L(Space}n being {#Alt_L(Space n)}. What do you think?

[lifeisstillgood]

Hi - I have been chatting with Mirabai on this issue briefly, and would be interested in helping out with the code if possible (Python dev, Plover newbie, no time whatsoever)

If there are any developer docs please do point them at me - and I will update the deploy instructions for FreeBSD too !

[samlh]

The user guide at doc/plover_guide.pdf describes the dictionary format. Otherwise, I haven't found any. Here's my quick description of an example data-flow as I understand it:

1. plover/oslayer/xkeyboardcontrol.py KeyboardCapture
2. plover/machine/sidewinder.py Stenotype.key_down/key_up
3. plover/steno.py Translator.consume_steno_keys
4. plover/formatting.py Formatter.consume_translation this is probably what needs changing for this task, specifically Formatter._translations_to_string
5. plover/oslayer/xkeyboardcontrol.py KeyboardEmulation.send_string/send_backspaces/send_key_combination see send_key_combination for the implementation of key combination syntax

All these are connected together by plover/app.py StenoEngine.init

[lifeisstillgood]

On Fri, Apr 12, 2013 at 11:48 PM, Samuel Harrington < notifications@github.com> wrote:

rmatting.py Formatter.consume_translation this is probably what needs changing for this task, specifically Formatter._translations_to_string

5. plover/oslayer/xkeyboardcontrol.py KeyboardEmulation.send_string/send_backspaces/send_key_combination see send_key_combination for the implementation of key combination syntax

All these are connected together by plover/app.py StenoEngine.init

Thank you

This will have to wait till early May at least - in the middle of conference prep and I have an old brain.

thanks for the pointers, I will see how it goes next month

Paul Brian paul@mikadosoftware 07540 456 115 twitter: @lifeisstillgood skype: paul.mikadosoftware

www.mikadosoftware.com

See your software improve with every change.

[jordancurve]

What do people think of having two generic "sticky" and "unstick" commands? The "sticky" command would make Plover only send KeyDown events (so, no KeyUp events) until Plover receives the "unstick" command, at which point it would send KeyUp events for all the keys pressed since the "sticky" command (in the reverse order they were pressed), and resume sending keyup events.

This would allow Plover hold down the Shift key for me while I click something with the mouse, a gesture which is used to select many items in several operating systems and applications. (http://www.webopedia.com/TERM/S/shift_clicking.html)

[balshetzer]

Another option would be to support a "down" and "up" version for each key that would only send the down or up key event respectively. Also an "all up" command to release any remaining down keys. The syntax could look something like: {#Shift_L_Down p_Down p_Up AllKeys_Up } which would be equivalent to {#Shift_L(p)}

[balshetzer]

Once concern is that stateful commands are likely to cause confusion like when we accidentally press caps-lock or num-lock. These have indicators to try to prevent confusion, which works sometimes.

[jordancurve]

Another use case to support is alt-tab to switch between programs. This works by holding down alt, tapping TAB a variable number of times until the program you want to switch to is selected, then releasing ALT.

[jordancurve]

Another related use case to consider is control clicking, that is, holding down the control key while clicking the mouse. Control clicking on a URL in gnome-terminal opens the URL in a new browser tab.

[morinted]

My biggest scare with sticky metakeys is the confusing that might come from the user not knowing how to turn off their modifier. It would be a serious scare to accidentally hit Windows key + sfraj. This concern was brought up by @balshetzer above.

An expiry could help, but then plover becomes real-time stateful and that's scary in its own right. I'm not sold on sticky metakeys.

[morinted]

One solution to the problem would be a "pause" key, as first proposed by @benreynwar

A pause key would let people hold down keys with {#keyname(pause2000)}, where 2000 is a value in milliseconds. That would let strokes hold down modifiers for a time.

[benreynwar]

I've been thinking about this as well because of the annoyance of not being able to Alt-Tab.

How about this:

• Allow commands {Alt_L_Down} and {Alt_L_Up} with the following additional rule
• If the previous translation contained a {Alt_L_Down} command and the current command contains neither a {Alt_L_Down} command nor a {Alt_L_Up} command then we emit an "Alt Up" before processing the current translation.

This means the {Alt_L_Down} would introduce state, but that state could not last longer than one translation.

For example to do Alt-Tab we would add to the dictionary: WHATEVER1: {Alt_L_Down Tab} WHATEVER2: --empty-- Then we can repeat the WHATEVER1 stroke to alt-tab between the different options, and hit WHATEVER2 or almost any other stroke to end the alt-tabing and go to the selected application.

[Elktro]

My biggest scare with sticky metakeys is the confusing that might come from the user not knowing how to turn off their modifier. It would be a serious scare to accidentally hit Windows key + sfraj.

What if sticky keys would only work with string with glue tag ({&...) and with keys presses defined as meta commands such as {#Tab}.