Add RU adaption of 'türkçe artı çok' layout #1460
Conversation
|
What you've done seems best. Using |
b03c888 to
419ae14
Compare
|
I renamed the utility method from |
|
This added a ton of commits to the top level. I must've forgotten to make sure its a squash merge. |
|
Since I usually work with merge not squash PR workflows I'm pretty careful to separate logical changes into commits that make sense to review, blame, and log separately. For example in this case having the commit that refactors an existing keyboard using new helper methods separate from the commit adding an all new layout is something that might be easier to review for other keyboard authors that want to similarly refactor. In the process of working on this I probably rewrote, split, combined and amended commits 50-100 times so that the end result would make sense as a commit sequence. On the other hand sometimes squashing makes sense to me too, e.g. I chose it for #1463 because all those commits in the PR were just churn noise over a tiny eventual change. Personally I'd like to see a case-by-case discretion available rather than just squashing everything, but it's your project. If everything just gets squashed I'd probably have split this up into at least 2 PRs. Is your concern changelog generation? I typically work with some sort of filter on that (e.g. |
|
It looks you already have the GH release notes generated from PR titles not the commit log, so the mix of technical detail in commits (great for Edit: It looks like you hand edited that, so yes either the |
|
Both changelog generation, and keeping the top-levels commits clean. I always prefer squash merging PRs in all my projects so I want to keep to that. If its two different features / additions, it should be two separate PRs anyway. |
Well that makes you almost a perfect heathen, but it is your sand box we are playing in not mine and I can respect that. 😉 |
Now that the dust has settled on
TRArti, my English/Turkish multilingual layout with extra typographic symbols, it is time to tackle my other need: Russian.This layout is an attempt to harmonize the overall layout, function, and symbol arrangement from TRArti (which fundamentally uses almost exactly the same letter layout as
ENThumbKey) while using almost the same letter layout asRUThumbKey. There are two letters in a different place (ёandю) that in the original Thumb Key layout were swipes towards the edge of the keyboard. I didn't like the edge swipes and have tried hard to avoid them for letters and reserved them for less frequently used symbols. I think the new positions of those two keys is more logical anyway, and should possibly be considered for the original layout too (to bee discussed in a different issue).One anoyance I ran into was that harmonizing symbol arrangements across 6 layout modes (TR normal/shifted/numeric, RU normal/shifted/numeric) was error prone. Moving
!to a different direction required doing so in six different places. To make this easier I added some helper methods to the layout arrays so that keys could me more easily copied and only the modified bits (typically the letters/numbers) changed rather than having to enter all the symbols in all the same positions all over again. This technique could be used in a lot of other layouts too, but I didn't refactor anything else yet. Obviously this is much less of a problem for layouts that specifically use different symbol arrangements on each mode, but when you're trying to keep the arrangement the same across modes this makes it quite a bit less tedious to get right. There might even be a cleaner way to do this, my Kotlin is fairly primative. @dessalines what do you think about this? Is there a more ergonomic way to make derivative layouts that I'm missing?