Keyboard handling rework #292
Conversation
- drop bad entries (invalid steno key) - add missing entries (so they get shown and can be configured in the GUI)
|
Traceback (most recent call last): |
|
It's an unrelated bug: #222 |
|
Any insight into #222 that you can give, Ben? He's reporting that error. Is there a fix we can make or should that PR be pulled as-is? |
|
Ok. I agree, since it's coming from a part of the code not touched directly by your patch; but naively wondering if changes to method call signatures in your patches could have caused it. Now I see that it's not the case. Other than that, it works as expected. I can use standalone plover in Emacs without it blonking on the function key presses. It also works fine with ibus-plover as before. The NKRO keyboard configuration dialog works fine and shows the same configuration as I'd set up previously with the addition of the new rows. I think this change set is good to go; I'm running Ubuntu vivid. |
|
Wonderful, I'll get to that tonight. Then I'll start looking at all your changes. No guarantees on getting it done before Halloween ;) |
|
I also noticed that in one file at least there are DOS line endings for On Thu, Oct 29, 2015, 13:36 Ted Morin notifications@github.com wrote:
|
|
I agree, ideally I'd like to be able to do have the code base be PEP8'd, but I'm not in favor of doing it for the sake of doing it. As I touch files I'll add the line ending and code style preferences. That being said, our code is seriously lacking adaptors for most of the C-libraries. |
|
Please explain what you mean by "our code is seriously lacking adaptors for Perhaps the line ending change should be done all at once, in one big On Fri, Oct 30, 2015, 09:35 Ted Morin notifications@github.com wrote:
|
|
https://www.youtube.com/watch?v=wf-BqAjZb8M He uses an adaptor in this video to make code more "Pythonic". For the line endings, I'll probably just use a |
We do not care about the keysym.
|
That video is way too long. Can you point to these c adapters another way?
|
|
I'm having trouble finding a brief explanation, but it's just a simple wrapping class to provide a more attractive interface to some kind of object; it's not C-exclusive. The point is to abstract away C/Java/other interfaces into something that is more native-feeling to Python. Instead of using libraryname.getObjectAtIndex(i), you could wrap around it so that you can use libraryname[i]. Here's a long post with code examples. I don't have lots of experience writing "good" Python code, and I'm really trying to dig into it while working with Plover. If you know of any good resources on Python best practices, I'd be interested in those, too. |
|
I remember learning about how Python uses "duck typing"... if it looks like On Sat, Oct 31, 2015, 09:04 Ted Morin notifications@github.com wrote:
|
|
So @KarlHegbloom, about your problem reported here benoit-pierre/ibus-plover#2 (comment):
|
Suppress all supported keys.
|
I finally got around to testing that. It's working fine. I think that the It's working wonderfully right now, using the function and number keys. No On Mon, Nov 2, 2015 at 4:53 AM, Benoit Pierre notifications@github.com
|
|
Yeah Plover basically doesn't stop running. No idea why it was designed
|
|
Plover keeps listening so it can process the on or toggle command. The
|
|
I wish I had more time for it now... after another 6 months or a year, I On Wed, Nov 4, 2015 at 9:23 PM, Hesky Fisher notifications@github.com
|
|
I think it's a good idea to have Plover running all the time - if you don't use a qwerty-keyboard but a steno machine, you'll want it to be ready to go at all times. And of course Plover needs to listen for the on/off strokes for qwerty users, as Hesky mentioned already. It might even be possible to let the suggestions work while you use qwerty by picking up the typed words and doing a lookup. For now I'm using my lookup script if I'm too lazy to fingerspell something and reach out to the qwerty-keyboard to type it. |
|
Good idea. Can you put that into a todo item in the source or a text file Perhaps that can be switched on and off also? Or maybe just minimized or On Thu, Nov 5, 2015, 05:14 Achim notifications@github.com wrote:
|
|
Noticed some conflicting behavior: If I have "space" in the noop line and turn on arpeggiate, it works and arpeggiates. If I turn off arpeggiate, it successfully still suppresses space. Great. However, if I add a key to both a steno line and the noop line, that key is just suppressed. I think I prefer the arpeggiate line behavior -> I should be able to add the whole alphabet to "noop" and still have my set keys work for steno. Does that make sense? |
|
Well, the keymap code does not do any sanity checks, so behavior with conflicting entries is undefined. I think having one key in multiple entries should not be allowed.
I don't think it make sense, I mean, why even go through the trouble of adding all those keys to the noop line? Unless of course, we were to support a more compact way to list those keys (like '[a-z]', or '[:alpha:]'. |
|
Either behavior is all right, as long as it's handled. In my opinion, I'd Furthermore, we don't report when keys are used twice in the list, as the On Sat, Nov 7, 2015 at 4:10 PM Benoit Pierre notifications@github.com
|
|
Well, there are 2 separate things:
I really don't like the current GUI: it would be better if the user could press the keys he want to use when editing an entry. Especially considering that Qwerty names are used, which is confusing when using another keyboard layout. Something like that:
In fact, with respect to keyboard layout, I would have preferred for the config to use key codes (and the GUI to display the corresponding key name for the user current keyboard layout). |
|
Yeah, I have no disagreement there. How would you like to handle the discrepancy that exists there now? |
|
Check if a key is used more than one time, and display a warning if it is ("key K bound multiple times, behavior is undefined") but keep on going. |
|
Sure. Would you add that to this PR?
|
|
How about merging it and I'll make another pull request for the GUI stuff. Maybe I'll look into improving the GU and using keycodes too, do you plan on making a release soon? It would be better to get those things right before making a new release, so we don't break compatibility with a released version. |
|
+2 I'm good with that. Release is not planned short term. We'll probably go
|
|
WIP version with the keymap conflicts check and better config GUI here: https://github.com/benoit-pierre/plover/tree/keyboard-handling-rework-bis |
Note:
oslayer/keyboardcontrolcode, since we can suppress and listen to all key events