Closed precondition closed 3 years ago
precondition
commented
3 years ago I'm not really a fan of copying and slightly rewriting the body of the ascii_art method in the hasattr branch of the fancy_art method. Not very DRY but I can't re-use the ascii_art method as is. (https://github.com/yskoht/keymapviz/pull/47/commits/6112fadaefadcf93e4131e853cd8ba79f577ae87#diff-ffe0fc7d2bd0248b9405c965845156e534233304c3e8b5389738767fe845b905R145-R149)
precondition
commented
3 years ago Bump
precondition
commented
3 years ago @yskoht Bump
precondition
commented
3 years ago What do you think about the naming of this function?
def get_final_ascii_art(self, ascii_art):
aa = self.__parse_ascii_art(ascii_art)
self.__ascii_art = [aa.format(*self.__legends(_)) for _ in self.keymaps]
return self.__ascii_artThis would let us replace duplicated code in
Any ASCII diagrams can easily be converted with the help of a new
--type fancyswitch.Examples :
(Some layers are truncated for readability)
This implementation works with any character you wish to use for the outline — with the exception of
__non_outline_chars = '*{} 0123456789'because those get used inside the key itself to let keymapviz know where to place the keycodes. That's why it works even with the arguably weird ergodox ASCII art which alternates between+andx, between!and|.The only time where I make an assumption on the characters used for outlines is in the first lines of
__get_box_drawing(self, left, down, up, right, center)in order to avoid a problem wherein the thumb cluster is linked to the alpha cluster when it shouldn't (this doesn't happen in my implementation):Fascinatingly, this new feature is resilient to errors in the source ASCII art! To illustrate my point, let's look at the ASCII art for the Kyria:
(for readability, only the left half without block comments is transcribed)
In the lower left corner of the alpha cluster, the first two
+should be-(because there are no bars/keys under them). If we go the very end of that same line with the incorrect+, we can see another error :.. Conventionally,.is used to represent the upper right corner in ASCII art of keyboards but that's not the edge, that character should be|.Nonetheless, you can see in the examples that it handles this situation beautifully. Something that can't be done with a simple search and replace that uses a lookup table ASCII→Box Diagram.
Some arbitrary choices had to be made but they're well-documented with comments.
This new feature has been successfully tested with keymaps of all the supported boards except for Lily58. The problem with the Lily is that it uses diagonal lines but I've tried using ╱ (
BOX DRAWINGS LIGHT DIAGONAL UPPER RIGHT TO LOWER LEFT) and the result was terrible. Even manually, doing a Lily keymap with fancy box drawing characters and diagonal keys is impossible because there doesn't exist a box drawing symbol that can neatly connect a diagonal line to a horizontal line for example, so we can say that the Lily is and cannot be supported.