Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keycodes refactor #171

Draft
wants to merge 11 commits into
base: main
Choose a base branch
from
Draft

Keycodes refactor #171

wants to merge 11 commits into from

Conversation

wismill
Copy link
Collaborator

@wismill wismill commented Apr 7, 2024

Simplify code and allow direct mapping of keys.

The new keys are only supported by XKB atm.

@wismill wismill force-pushed the keycodes/refactor branch 6 times, most recently from cf73dfa to f418454 Compare April 7, 2024 21:37
- Moved all the info about scan codes in the YAML file
- Added a dedicated class `Key` that gather all the scan codes
- Simplify the code
Using ASCII art to declare the layout is limited to the keys declared in
the geometries.

Added an extra section `mapping` to the TOML layout configuration file,
that enable mappings key explicitly with a dictionary.
@wismill
Copy link
Collaborator Author

wismill commented Apr 7, 2024

@fabi1cazenave I left as draft as it:

  • still misses tests
  • need to add warnings if key is not supported

@wismill
Copy link
Collaborator Author

wismill commented Apr 8, 2024

  • Added tests for XKB.
  • Added Windows scan codes. Require writing tests, but above all testing it @Geobert.

@wismill
Copy link
Collaborator Author

wismill commented Apr 8, 2024

Added test for Windows and improve VK handling, especially to avoid same VK with multiple mappings.

@fabi1cazenave fabi1cazenave added the enhancement New feature or request label Apr 9, 2024
Copy link
Collaborator

@fabi1cazenave fabi1cazenave left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably didn’t want any review at this stage but I had to give a look. :-) Impressive work !

I’m not sure the hand name is very self-explanatory. And I’d like to see a TOML file with your custom mapping proposal. ^_^

kalamine/data/qwerty_vk.yaml Outdated Show resolved Hide resolved
web: "Digit3"
windows: "T04"
macos: "20"
hand: null
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick, maybe the following could be easier to read :

digits:
  { web: Digit1, xkb: ae01, windows: T02, macos: "18", hand: null }
  { web: Digit3, xkb: ae02, windows: T03, macos: "19", hand: null }
  { web: Digit3, xkb: ae03, windows: T04, macos: "20", hand: null }

FTR & TBH I disliked this change… until I saw how it improves the code readability.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. But wouldn’t a CSV format be even more adapted then?

kalamine/generators/klc.py Show resolved Hide resolved
kalamine/generators/web.py Show resolved Hide resolved
kalamine/generators/xkb.py Show resolved Hide resolved
kalamine/key.py Outdated
return bool(self.category & KeyCategory.AlphaNum)


KEYS = Key.load_data(load_data("scan_codes"))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line triggers my PTSD. :-)

I like data classes but I’m not a fan of creating void objects first, then fill them with data. This looks like an anti-pattern to me.

Couldn’t we use the constructor instead for that , and drop all parse / load_data methods in these data classes ? Otherwise, factory functions parsing data and returning such objects would make sense.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed in the Discord server, we are not creating void objects. It is merely putting the parsing functions under a proper namespace.

I think you mean the initializer __init__, not the constructor __new__.

It is not a good idea to modify the initializer nor the default constructor, because they are created automatically with @dataclass.

But in fact Key.parse is just another constructor, as you cannot overload functions properly in Python.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the Key.load_data method has a poor name. Fixed.

@@ -47,15 +47,33 @@ class Layer(IntEnum):
ALTGR = 4
ALTGR_SHIFT = 5

@classmethod
def parse(cls, raw: str) -> Optional["Layer"]:
rawʹ = raw.casefold()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is probably a dumb question but is this trailing single quote sign a special Python stuff ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is not Python specific: it a prime, and I find it very practical for closely related variables. Common practice from Haskell I guess.

"esc": {"base": "\x1b", "shift": "(ae11)"},
# NOTE: clone key
"henk": "(lsgt)",
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this is a work in progress. Otherwise the comments could be more explicit, I’m not following you here. 🙇

Copy link
Collaborator Author

@wismill wismill Apr 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated. Is it clearer?

@@ -47,15 +47,33 @@ class Layer(IntEnum):
ALTGR = 4
ALTGR_SHIFT = 5

@classmethod
def parse(cls, raw: str) -> Optional["Layer"]:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in another comment, I’m not a fan of having a parse method to be called after the object has been instantiated. To me it should either be a constructor, or we should have a factory that returns such an object.

Copy link
Collaborator Author

@wismill wismill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated a few things

kalamine/data/qwerty_vk.yaml Outdated Show resolved Hide resolved
kalamine/key.py Outdated
return bool(self.category & KeyCategory.AlphaNum)


KEYS = Key.load_data(load_data("scan_codes"))
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed in the Discord server, we are not creating void objects. It is merely putting the parsing functions under a proper namespace.

I think you mean the initializer __init__, not the constructor __new__.

It is not a good idea to modify the initializer nor the default constructor, because they are created automatically with @dataclass.

But in fact Key.parse is just another constructor, as you cannot overload functions properly in Python.

kalamine/key.py Outdated
return bool(self.category & KeyCategory.AlphaNum)


KEYS = Key.load_data(load_data("scan_codes"))
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the Key.load_data method has a poor name. Fixed.

web: "Digit3"
windows: "T04"
macos: "20"
hand: null
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. But wouldn’t a CSV format be even more adapted then?

@wismill
Copy link
Collaborator Author

wismill commented Jul 5, 2024

Not going to work on kalamine anymore.

@wismill wismill closed this Jul 5, 2024
@fabi1cazenave fabi1cazenave reopened this Aug 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants