Improve formatting for alternate key layouts.

[KarlHegbloom]

Improved code formatting and experimented with alternate key layouts for
my new Noppoo Choc-84 / N-Key-USB keyboard.

I think you'll not want some of the whitespace only changes; some are inadvertent. Also I've got the alternative key mapping enabled by default here. I'm new at this. I think you will want the reformatted alternate keyboard layout definitions.

How can that be put into a configuration file? Can that same configuration be caused to work with standalone Plover? (Though I really prefer to use the ibus like this. It's great to have an icon for switching it.)

[benoit-pierre]

Thanks, but since the next version of Plover allow configuring the keyboard mapping, the plan is to use its configuration instead of hard-coding the mapping in the source. See my last commit if you want to test this (you'll need to install Plover from source).

[KarlHegbloom]

The problem is that when I set the keymap in Plover to:

keymap = [["S-", ["F1", "1"]], ["T-", ["F2"]], ["K-", ["2"]], ["P-",
["F3"]], ["W-", ["3"]], ["H-", ["F4"]], ["R-", ["4"]], ["A-", ["e"]],
["O-", ["r"]], ["*", ["F5", "5", "F7", "7"]], ["-E", ["u"]], ["-U", ["i"]],
["-F", ["F8"]], ["-R", ["8"]], ["-P", ["F9"]], ["-B", ["9"]], ["-L",
["F10"]], ["-G", ["0"]], ["-T", ["F11"]], ["-S", ["-"]], ["-D", ["F12"]],
["-Z", ["="]], ["#", ["F6", "6"]]]

... and then turn on Plover and try to use it to enter text into Emacs, the
editor sees the function key presses before Plover does, and it doesn't
work right. I just tested your ibus-plover, with Plover configured as
above, and it does work. Ibus gets the keys before Emacs24 does, since
emacs is using xim, as far as I understand things. Am I right?

Plover without ibus is using the XRECORD and XTEST extensions. Those are
not really the right way; it's a hack. I really think that plover just
needs to be an input method, via ibus like this.

I wonder if you've tried the other ibus-plover that's on github, by Rick
Lupton? His appears to have surrounding-text-awareness support. Maybe his
code can be merged? I have not tried to use it yet.

On Fri, Oct 16, 2015 at 3:12 PM, Benoit Pierre [email protected]
wrote:

Thanks, but since the next version of Plover allow configuring the
keyboard mapping, the plan is to use its configuration instead of
hard-coding the mapping in the source. See my last commit
0362cf0
if you want to test this (you'll need to install Plover from source).

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[email protected]
http://karlhegbloom.blogspot.com

[benoit-pierre]

The problem is that when I set the keymap in Plover to: keymap = [["S-", ["F1", "1"]], ["T-", ["F2"]], ["K-", ["2"]], ["P-", ["F3"]], ["W-", ["3"]], ["H-", ["F4"]], ["R-", ["4"]], ["A-", ["e"]], ["O-", ["r"]], ["*", ["F5", "5", "F7", "7"]], ["-E", ["u"]], ["-U", ["i"]], ["-F", ["F8"]], ["-R", ["8"]], ["-P", ["F9"]], ["-B", ["9"]], ["-L", ["F10"]], ["-G", ["0"]], ["-T", ["F11"]], ["-S", ["-"]], ["-D", ["F12"]], ["-Z", ["="]], ["#", ["F6", "6"]]] ... and then turn on Plover and try to use it to enter text into Emacs, the editor sees the function key presses before Plover does, and it doesn't work right. I just tested your ibus-plover, with Plover configured as above, and it does work. Ibus gets the keys before Emacs24 does, since emacs is using xim, as far as I understand things. Am I right? Plover without ibus is using the XRECORD and XTEST extensions.

It's something that can (and should) be fixed in Plover. Right now, the implementation assumes the layout will be confined to the number bar + the 3 letter rows. So only those rows are suppressed, which is why you're having trouble when using the function row.

I'm thinking another entry should be added to the configuration dialog: a "NO-OP" line; the keys from this entry don't translate to a steno key, but they are suppressed. E.g. the 'standard' (default) layout would become:

[
["S-", ["a", "q"]],
["T-", ["w"]],
["K-", ["s"]],
["P-", ["e"]],
["W-", ["d"]],
["H-", ["r"]],
["R-", ["f"]],
["A-", ["c"]],
["O-", ["v"]],
["*", ["t", "g", "y", "h"]],
["-E", ["n"]],
["-U", ["m"]],
["-F", ["u"]],
["-R", ["j"]],
["-P", ["i"]],
["-B", ["k"]],
["-L", ["o"]],
["-G", ["l"]],
["-T", ["p"]],
["-S", [";"]],
["-D", ["["]],
["-Z", ["'"]],
["#", ["1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-", "="]]
["NO-OP", ["`", "z", "x", "b", ",", ".", "/", "\"]], 
]

Of course, all keys used by the layout should be suppressed too, so you can use the function row if you want.

Ideally, an ARPEGGIATE entry should be added too, since using an alternate "function keys" layout will not be ergonomic if the spacebar must still be used to arpeggiate.

Finally, one last thing missing for good keyboard support: being able to configure a shortcut for toggling Plover on and off. Right now you're supposed to use a dictionary entry with {PLOVER:TOGGLE}, but this is something that can never work right for the suspend -> resume transition: because when Plover is suspended the keyboard is not suppressed. You can't reliably suppress those keys after the fact, even if those keys are on alphanumeric rows: one example is if you're in VIM command mode, you can't backspace over the results from pressing those keys. And of course, it's even worse if you're layout/stroke is using the function keys. So maybe add 3 more entries: PLOVER:TOGGLE, PLOVER:RESUME, and PLOVER:SUSPEND.

@morinted: what do you think?

Those are not really the right way; it's a hack. I really think that plover just needs to be an input method, via ibus like this. I wonder if you've tried the other ibus-plover that's on github, by Rick Lupton?

I have not.

His appears to have surrounding-text-awareness support. Maybe his code can be merged? I have not tried to use it yet.

I have not looked at the code, but note that in my version surrounding-text support is used too: when available and in immediate mode.

[KarlHegbloom]

Rick Lupton says that his version works, but it did not. It was difficult
to build a Debian package, and then it did not function.

Your ibus-plover does not work right in TeXmacs unless I run the ibus-setup
program and uncheck the "embed pre-edit" box.

It does not work at all in Kwrite, where ibus-table based input methods,
like compose and LaTeX work just fine.

I really like the pop-up chooser thing with those ibus-table based input
methods. It would be really nifty to have that with this, sort of like
having the StenoTray app embedded in it. I bet it can be made to suggest
shorter strokes, autocomplete often used words, and allow entry of
user-defined briefs right then and there, inline as you go; and it supports
a settings dialog, which is another thing this needs; I guess that when
actually doing steno for hire, there's not time to enter new briefs, and
you'll want the raw stroke to just appear, to be fixed up later so you
don't miss anything? A spell-checker based guesser with a choice list would
make that better, especially for closed captioning or whatever, so it
doesn't have to be gone over a second time.

So I wonder if subclassing the ibus-table would be the right way to do
this? I read it's code last night. I need to study Plover now, and think
about it. What do you think about this? Any ideas?

On Sun, Oct 18, 2015 at 7:34 AM, Benoit Pierre [email protected]
wrote:

The problem is that when I set the keymap in Plover to: keymap = [["S-",
["F1", "1"]], ["T-", ["F2"]], ["K-", ["2"]], ["P-", ["F3"]], ["W-", ["3"]],
["H-", ["F4"]], ["R-", ["4"]], ["A-", ["e"]], ["O-", ["r"]], ["*", ["F5",
"5", "F7", "7"]], ["-E", ["u"]], ["-U", ["i"]], ["-F", ["F8"]], ["-R",
["8"]], ["-P", ["F9"]], ["-B", ["9"]], ["-L", ["F10"]], ["-G", ["0"]],
["-T", ["F11"]], ["-S", ["-"]], ["-D", ["F12"]], ["-Z", ["="]], ["#",
["F6", "6"]]] ... and then turn on Plover and try to use it to enter text
into Emacs, the editor sees the function key presses before Plover does,
and it doesn't work right. I just tested your ibus-plover, with Plover
configured as above, and it does work. Ibus gets the keys before Emacs24
does, since emacs is using xim, as far as I understand things. Am I right?
Plover without ibus is using the XRECORD and XTEST extensions.

It's something that can (and should) be fixed in Plover. Right now, the
implementation assumes the layout will be confined to the number bar + the
3 letter rows. So only those rows are suppressed, which is why you're
having trouble when using the function row.

I'm thinking another entry should be added to the configuration dialog: a
"NO-OP" line; the keys from this entry don't translate to a steno key, but
they are suppressed. E.g. the 'standard' (default) layout would become:

[
["S-", ["a", "q"]],
["T-", ["w"]],
["K-", ["s"]],
["P-", ["e"]],
["W-", ["d"]],
["H-", ["r"]],
["R-", ["f"]],
["A-", ["c"]],
["O-", ["v"]],
["*", ["t", "g", "y", "h"]],
["-E", ["n"]],
["-U", ["m"]],
["-F", ["u"]],
["-R", ["j"]],
["-P", ["i"]],
["-B", ["k"]],
["-L", ["o"]],
["-G", ["l"]],
["-T", ["p"]],
["-S", [";"]],
["-D", ["["]],
["-Z", ["'"]],
["#", ["1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-", "="]]
["NO-OP", ["`", "z", "x", "b", ",", ".", "/", ""]],
]

Of course, all keys used by the layout should be suppressed too, so you
can use the function row if you want.

Ideally, an ARPEGGIATE entry should be added too, since using an
alternate "function keys" layout will not be ergonomic if the spacebar must
still be used to arpeggiate.

Finally, one last thing missing for good keyboard support: being able to
configure a shortcut for toggling Plover on and off. Right now you're
supposed to use a dictionary entry with {PLOVER:TOGGLE}, but this is
something that can never work right for the suspend -> resume transition:
because when Plover is suspended the keyboard is not suppressed. You can't
reliably suppress those keys after the fact, even if those keys are on
alphanumeric rows: one example is if you're in VIM command mode, you can't
backspace over the results from pressing those keys. And of course, it's
even worse if you're layout/stroke is using the function keys. So maybe add
3 more entries: PLOVER:TOGGLE, PLOVER:RESUME, and PLOVER:SUSPEND.

@morinted https://github.com/morinted: what do you think?

Those are not really the right way; it's a hack. I really think that
plover just needs to be an input method, via ibus like this. I wonder if
you've tried the other ibus-plover that's on github, by Rick Lupton?

I have not.

His appears to have surrounding-text-awareness support. Maybe his code can
be merged? I have not tried to use it yet.

I have not looked at the code, but note that in my version
surrounding-text support is used too: when available and in immediate mode.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[email protected]
http://karlhegbloom.blogspot.com

[benoit-pierre]

There are basically 3 uses cases:

• an application using the old crummy XIM support: meaning no surrounding text support, like VIM, or xterm
• GTK application: the GTK input method plugin for ibus is used, surrounding text is supported
• QT application: the QT input method plugin for ibus is used, surrounding text should be supported now, but: as noted in the readme, I had to patch ibus-qt to handle X11 auto-repeat (also ibus-qt is for QT4, what about QT5 applications?)

So which one is it for TeXmacs/Kwrite?

[benoit-pierre]

OK, so I just installed TeXmacs, and with ibus-qt installed too, ibus-plover does not work, but without it, then it works.. I guess it switches to XIM.. So I don't know, maybe the interface for QT changed? The ibus-qt project on Google Code is now read only, and the github version has not been updated in a year.

[KarlHegbloom]

I found out that in Qt5, the ibus support is supposed to be built-in: https://www.google.com/webhp?q=qt5%20ibus ​ http://lists.qt-project.org/pipermail/development/2013-January/009271.html I'm not surprised that it doesn't work right in TeXmacs. What I see when it's set to embed the preedit text into the application window is ibus drawing a window and then TeXmacs redraws right over the top of it because it's not aware of ibus. I don't know why kwrite works with the ibus-table input methods but not with the ibus-plover.

[benoit-pierre]

For some reason, the keycode is not valid anymore... That's why it's not working... sigh

[KarlHegbloom]

With QT_IM_MODULE=ibus (default setting on Ubuntu when ~/.xinputrc has
"run_im ibus" in it) the KDE app "kate", which is linked to Qt5, accepts
ibus input via the ibus-table methods, but not ibus-plover. Why?

What do you think about implementing it as a subclass of ibus-table? Is
that feaseable?

On Sun, Oct 18, 2015 at 5:14 PM, Benoit Pierre [email protected]
wrote:

For some reason, the keycode is not valid anymore... That's why it's not
working... sigh

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[email protected]
http://karlhegbloom.blogspot.com

[benoit-pierre]

As stated in my previous comment, something has changed when dealing with QT: the keycode field is not valid anymore, that's why ibus-plover does not work.

[KarlHegbloom]

Annoying. Did you see these? http://lists.qt-project.org/pipermail/development/2015-July/022460.html https://bugs.archlinux.org/task/38431 ​

[KarlHegbloom]

What about "inputattach" | keyboard_emulation_or_something | ibus |
ibus-plover for the steno machine on a serial or USB link?

What's it like on Windows and Mac in terms of input-method support? Does
ibus run there? (I don't really care and won't help develop that but it
might be of interest to people who actually use Windows and Mac.)

On Sun, Oct 18, 2015 at 5:26 PM, Karl Hegbloom [email protected]
wrote:

Annoying.

Did you see these?

http://lists.qt-project.org/pipermail/development/2015-July/022460.html
https://bugs.archlinux.org/task/38431

​

[email protected]
http://karlhegbloom.blogspot.com

[benoit-pierre]

OK, so I fixed the bug in ibus-qt, see here. This is for fixing QT4 applications.

As for QT5 applications, I rebuilt libibusplatforminputcontextplugin.so from source (git master), and now kwrite works, so this is fixed in upstream.

[KarlHegbloom]

Are you using Debian or Ubuntu? Will you send them a heads-up and ask for
them to incorporate the patch please?

On Sun, Oct 18, 2015 at 8:22 PM, Benoit Pierre [email protected]
wrote:

OK, so I fixed the bug in ibus-qt, see here
benoit-pierre/ibus-qt@f0bd051.
This is for fixing QT4 applications.

As for QT5 applications, I rebuilt libibusplatforminputcontextplugin.so
from source (git master), and now kwrite works, so this is fixed in
upstream.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[email protected]
http://karlhegbloom.blogspot.com

[benoit-pierre]

I'm on Arch Linux. I'll create a merge request for ibus-qt tomorrow, but now I'm off to bed (it's 4:26 here).

[KarlHegbloom]

Thanks. Get some sleep. It's 20:29 here. :-) I've got to do other work
during the week; this is sort of "hobby" work, at least until I'm done with
the other project.

On Sun, Oct 18, 2015 at 8:28 PM, Benoit Pierre [email protected]
wrote:

I'm on Arch Linux. I'll create a merge request for ibus-qt tomorrow, but
now I'm off to bed (it's 4:26 here).

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[email protected]
http://karlhegbloom.blogspot.com

[morinted]

• How about suppressing keys that are being used in the steno layout, automatically?
• Not sure about a TPHAOP (DUPT>TPHAOP>noop) noop line, but it could happen in some form.
• I understand your concern with the toggle shortcut. I, too, have had issues using it in Vim. I've gotten used to just moving out of my text editor to enable and disable Plover, but I see that that's bad usability. Is there a reliable way to catch global shortcuts in all operating systems that would let us make a GUI interface for Plover? A nice UI addition would be showing users what Plover toggle strokes are in their dictionaries at the same time. Like, say I go to set a shortcut to activate Plover, but then see that there's a strokes in the default dictionary that maps to Plover:toggle.

cc @stenoknight

[benoit-pierre]

Push request for Plover with the proposed keyboard handling changes here: openstenoproject/plover#292

[KarlHegbloom]

Thank you. Perhaps I'll have some time for this over the weekend.

On Thu, Oct 29, 2015 at 11:38 AM, Benoit Pierre [email protected]
wrote:

Push request for Plover with the proposed keyboard handling changes here:
openstenoproject/plover#292
openstenoproject/plover#292

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[email protected]
http://karlhegbloom.blogspot.com

[KarlHegbloom]

I found a problem with the new keyboard handling when function and number
keys, plus e r u o are bound for steno in Plover. When plover is on, it
works great, but when I switch it off, those key are still suppessed.

On Thu, Oct 29, 2015 at 12:14 PM, Karl Hegbloom [email protected]
wrote:

Thank you. Perhaps I'll have some time for this over the weekend.

On Thu, Oct 29, 2015 at 11:38 AM, Benoit Pierre [email protected]
wrote:

Push request for Plover with the proposed keyboard handling changes here:
openstenoproject/plover#292
openstenoproject/plover#292

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[email protected]
http://karlhegbloom.blogspot.com

[email protected]
http://karlhegbloom.blogspot.com

[benoit-pierre]

@KarlHegbloom: just to be clear, you're speaking about a problem when using Plover with this openstenoproject/plover#292, not with ibus-plover?

[KarlHegbloom]

Oh, yeah, sorry. I replied to the wrong email. Doh.

On Sun, Nov 1, 2015 at 3:42 PM, Benoit Pierre [email protected]
wrote:

@KarlHegbloom https://github.com/KarlHegbloom: just to be clear, you're
speaking about a problem when using Plover with this
openstenoproject/plover#292
openstenoproject/plover#292, not with
ibus-plover?

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[email protected]
http://karlhegbloom.blogspot.com