Input Diacritics

[flide]

'umlaut' is pretty popular in demand, figure out how to incorporate them into the keyboard.

[flide]

All character with umlauts :
ä, ë, ï, ö, ü, ÿ, Ä, Ë, Ï, Ö, Ü, Ÿ

Other characters we should think about as well :

à, è, ì, ò, ù, À, È, Ì, Ò, Ù
á, é, í, ó, ú, ý, Á, É, Í, Ó, Ú, Ý; ð, Ð
â, ê, î, ô, û, Â, Ê, Î, Ô, Û
ã, ñ, õ, Ã, Ñ, Õ
å, Å
æ, Æ; œ, Œ; ß
ç, Ç
ø, Ø, ¢
¿, ¡, €

Seems like most are modifying vowels.

[WuerfelDev]

I don't think the keyboard needs to contain all the umlauts, but only those relevant for the language. In German as example it would reduce the list to: äöüÄÖÜß

[JapanYoshi]

Don't forget the Capital Eszett!

[reacherjack422]

How hard would it be to add the umlaut by combining it with the gesture already there? I'm not sure if the German layout is different from English, but a possible solution would be, for example using "a" :

Swipe from circle to right quadrant then to the top quadrant and back to the circle (which would give "a" if you lift a finger) but then without lifting your finger, go back to the top quadrant one more time then bring it back to the circle to give a "ä" .

It seems like you could just choose a quadrant to always go back to without crossing a line to modify the letter. Maybe instead of going to the top, choose the left quadrant or bottom to double back on for "ã"

A possible issue is the current layout doesn't appear to let you keep typing if you move your finger in such a way, so you might have to lift a finger and delete the inserted space to keep typing? (Appears to be related to #63)

[davidoskky]

@reacherjack422 That could be a great way to do it in my opinion; in Italian for example the two accents are needed to form all letters (àèìòùé), in this way I could have a couple movements (although not very natural) to add those accents.
The main problem remains having alphabets with more than 32 characters; right now crossing more than 4 lines produces capital letters, it could be possible to have the extra letters in a fifth line crossing.
This is not at all a good solution as movements regarding those letters will get longer and longer.

[reacherjack422]

@davidoskky I don't know the limitations or complications involved in implementing into the app, but to me it seems like a possible solution would be to add a letter at the very top of each line.

A rough example, if there was a ñ at the tip of the line starting with "a" and "y", let the user swipe either from the top section to the right section, or from the right section to the top (both would do the same thing) and then swipe back over that same line before returning to the circle.

So: from circle through y and then to a and then back to y before returning to the circle. Or from a to y to a to circle.

I'm just brainstorming what might seem easier without adding an extra line...

[flide]

I think you guys are on track with how the keyboard implements the input for Esperanto specific characters.

https://github.com/flide/8VIM/blob/f83bb5ca17f6dc230f6ffaa463351d8e2fe844db/8vim/src/main/res/raw/keyboard_actions.xml#L567

If it makes sense, I guess, we are already on track and simply need to agree on the gesture for umlauts.

Also, following gestures are already taken:
Top -> center : hides the keyboard
left -> center : paste from clipboard
right -> center : start selection backwards

Also, In principle I don't allow gestures to cross the center.
General idea is : "Start in the Center, End in the Center". Obviously, the makers of rules are the first ones to break them.

[davidoskky]

Sorry, I did not know about how the Esperanto characters worked.
To me it looks like a great way to introduce all diacritics: moving back one sector enters in diacritics modality, from where i can select any diacritic to add on the character moving clockwise or counterclockwise.
The system is in this way very flexible and allows introducing all the diacritics needed on all the characters.
Therefore if I compose an 'a' with right -> top I can go back before going center, therefore top -> right.
At this point I can move either clockwise or counterclockwise to introduce the various diacritics.
For example:
center = ä; top -> center = à; bottom -> center = â
Doing the same movements with another letter should introduce the same diacritics consistently: e ë è ê
This will prevent having to learn a specific pattern for every single character.

However I do not really have any suggestion on which gestures to assign to each diacritic, this behavior is very language dependent.
As far as I know a mechanism like this would be great for introducing languages like Hindi, in which you do not have diacritics but you could use these combinations to insert the vowels or to combine the consonants ( क -> कू, त -> त्)

[Roborbio]

I totally agree with davidoskky, but i think that the only way to solve that is to slowly implement every lenguage.

[Glitchy-Tozier]

@davidoskky I don't fully understand your proposal. Could you please describe the exact movements you would perform for a few letters?
(let's use ä, é, and, because it's important for German ß, a special form of s)

However I do not really have any suggestion on which gestures to assign to each diacritic, this behavior is very language dependent.

For now, just decide what gestures you feel like using.

I can't wait until i can finally start using this keyboard as a german-speaker!

[davidoskky]

@Glitchy-Tozier sorry for the bad explanation, I will try to clarify:
Once i go back one line I will select the letter in the same way I would have done going back to center, going back will tell the program I want to insert that letter with a diacritic or a modification.
I will therefore first select the letter a, then select the diacritic umlaut and then confirm going center to get ä.
At this point we can define 9 different types of diacritics or modification: if I immediately go center I will get the umlaut, if I cross 1 line back and then center (going the opposite direction of the original movement) I will insert a grave accent (à), if I cross 1 line forward and then center I will insert the Esperanto character as it is already implemented.
Of course you can have a different diacritic crossing 1-4 lines back and forward, therefore a total of 9 different diacritics or letter modifications.
à: right, top, right, top, left, center
è: bottom, left, bottom, right, center
ü: bottom, right, top, right, center
ë: bottom, left, bottom, center

I am not a German speaker, therefore I do not know about the best way to insert the ß character, and I do not know how common it is. I guess this system could be used as well, as far as I know grave accents are only used over vowels, it may be the same for the umlaut. We could substitute the diacritic combination for the umlaut or the grave accents on the consonants to form one of its modified forms.
Since you say ß is a special form of s, we could obtain it by applying a modification on the letter s.
ß: top, left, top, center

I'm not sure I can suggest good gestures, I am mainly an Italian speaker and I would therefore place the acute and grave accents in the easiest positions.
If different keyboard layouts will be implemented this will not be a problem at all, but creating a Latin alphabet with all the diacritics is just too difficult, in this case I think a little bit of research would have to be done.

If this is just needed for a quick implementation before adding the different layouts i would say:
umlaut: immediately center
grave accent: 1 back -> center
acute accent: 2 back -> center
Esperanto: 1 forward -> center (just how it is now)

[Glitchy-Tozier]

Ok, I understand now.
Long post ahead.

I want to mention a few ideas for alternatives that present slightly fewer options to the user, but may be WAY quicker:

Option 1: Adding diacritics AFTER writing the characters

The idea:

This is somewhat similar to what has been proposed before, but sounds a little faster:

1. The user writes a letter which he wants to modify
   a = center -> right -> top -> center
2. Then, the user does an "add diacritic"-movement. For example, for umlauts, that movement could be
   .. = center -> top -> center
3. This "add diacritic"-movement would then cause the "normal" letter to be replaced by a modified one. This means, that
   ä = center -> right -> top -> center -> top -> center.

This is all that's needed for German. (s should be turned into ß in every sector.) For languages that can use multiple diacritics, we can use all four sectors.
For example:
a-Z = do no extra movements
à, è, ì, ò, ù, À, È, Ì, Ò, Ù = add (center ->) left -> center
á, é, í, ó, ú, ý, Á, É, Í, Ó, Ú, Ý; ð, Ð = add (center ->) right -> center
â, ê, î, ô, û, Â, Ê, Î, Ô, Û = add (center ->) top -> center
ã, ñ, õ, Ã, Ñ, Õ = add (center ->) bottom -> center

Why use it?

I like this way of doing it, because there is even more diacritic consistency. umlauts are always in the top-sector, no matter where you come from. Compare this to the current ĉ-method, where this diacritic-orientation rotates depending on where your letter is.
Also, it kind-of makes sense positioning-wise. â has a kind of top-heavy addon. é has a line going to the right. (hence the center -> RIGHT -> center movement.
Of course, users should be able to configure on their own, which sectors to assign which diacritics to.

(oh, and s should always turn into ß, on every sector I think. @davidoskky, it's somewhat common, definitely more common than something like q or y in German.)

Problems with this idea:

It can only support 4 (user-chosen) diacritics. In our previous input methods, we could spin around the circle infinitely to access all diacritics on our 6th line crossing.
(though honestly, at that point switching to a different keyboard would probably be almost as fast)

Option 2: Breaking some rules :)

This is an option that sounds REALLY NICE for languages, that don't have multiple modified versions of the same letter.
For example, this could work in German, where there's only
a -> ä
However, in Italian, where there is (i think)...
e -> è, é
...the following proposal is not productive. I'd still think we should consider giving users of non-diacritic-heavy languages the choice.

The idea:

This removes the extra-motion-component entirely. Basically, you would type a diacritic letter by lifting your finger off the screen in the sector of the letter, and then finish the movement. Here's a few examples to make this more clear.
ä = center -> right -> top -> quickly lift off your finger from the screen then put it back down -> center
ö = center -> bottom -> right -> quickly lift off your finger from the screen then put it back down -> center
ü = center -> bottom -> right -> top -> quickly lift off your finger from the screen then put it back down -> center
(ß = center -> top -> left -> quickly lift off your finger from the screen then put it back down -> center)

Why use it?

This is amazing for languages such as German, as it gets rid of all extra movements. Just quickly raising your finger. This should be way quicker than all the previous options and it should be more comfortable, as there's no "high energy" -movements (= big direction changes as described here: https://8pen.blogspot.com/.
Compare that to those other options, where you have to

1. Travel extra distance with your finger
2. Do pretty hefty direction-changes.

Problems with this idea:

There are two big problems:

1. Italian speakers
   (Sorry, i just thought it was funny. What I meant was languages that need multiple â, á, à, â and ä cannot use this.)
2. It clashes with one of the preexisting rules:

Also, following gestures are already taken:
Top -> center : hides the keyboard
left -> center : paste from clipboard
right -> center : start selection backwards

This means, we probably should either specify or change those rules (examples for top->center):
Specify:
"Only when the trail hasn't previously stopped in the top-sector, does top -> center hide the keyboard."
OR
"Only when the trail hasn't previously stopped in the top-sector or the stop lasted longer than 1 second, does top -> center hide the keyboard."

Change:
Instead of
Top -> center : hides the keyboard
, we could kind of...
Top -> bottom : hides the keyboard.

Also, In principle I don't allow gestures to cross the center.

Yes, I read this, but I don't really understand why. There already are center -> right and center -> left shortcuts which break the center -> ... -> center principle. Also, I'm perfectly fine with just going for the "Specify"-route.

.

This was more than half an hour of work, I hope it's somewhat comprehensible.
I think both of those options should be good ideas, and both could simultaneously be implemented (and even be used at the same time)
Users should be able to switch them on & off though, if they for some reason prefer not having one of them exist.
Thoughts?

[davidoskky]

@Glitchy-Tozier the first idea you propose is the same coming from @reacherjack422 as far as I can tell.
I do really like the methodology you proposed in fact, I have tried doing the various movements and to me it seems faster to add the diacritic with a subsequent movement.
Therefore I prefer the usability of your proposal to that of mine.
My only concern was the limit of 4 diacritics; i checked wikipedia and it looks like no language with Latin alphabet uses more than 4 different diacritics on the same letter.
Therefore this method looks completely motivated to me, and right now it looks like the best proposal.

Regarding the second method proposed there obviously is the "Italian speaker" problem... however I guess it could be a nice optional feature if it can be implemented.
Of course I would not prioritize developing this particular methodology over the other.

Both these methods rely on language dependent keyboard schemes. We could start implementing the four movements you suggested, but in order to have this keyboard usable by everyone an option to change keyboard scheme is absolutely needed.
If keyboard schemes are not implemented a way to choose the diacritics that can be inserted is needed, this could be a good Idea even if keyboard schemes are implemented in fact: I could start speaking German and therefore I could use èéë who wouldn't all be included in the Italian scheme nor in the German one. Changing a setting I could insert the umlaut and be able to write in two different languages.

[Glitchy-Tozier]

@davidoskky I agree with pretty much everything.

• It's nice to know that no language uses more than 4 diacritics.
• The "add diacritic"-movement seems like a good idea.
• I agree that the first approach from my post should be prioritized over the second. I just hope the second, too, will eventually be implemented, for the love of fast German typing. (and to the benefit of other diacritic-limited languages)
• I agree that the user should be able to configure which sector adds which diacritic. This is especially helpful if the user is used to rapidly switching between languages that use different diacritics. (for example when alternating between Italian and German)

Edit:

Actually, now that I think about it, every language could benefit from having both options present. In every language that uses diacritics there must be a "most commonly used diacritic".
Users of any language could use the quickly-lift-finger-method (the second one I described) to add the most used diacritic. They then could use the first method i have described to use up to four other characters. This is great because

1. It makes inputting diacritics faster for every language
2. It additionally gives a layout up to five different diacritics.
   (Alternatively, users could of course change the settings in a way to let them place the same diacritic in fife different ways.)

But yes, if we need to choose, first implement the first option I described. (This:)

Option 1: Adding diacritics AFTER writing the characters

Regarding @reacherjack422's idea:

It seems I didn't quite understand some of the first messages. However, now that I have re-read them, there actually seem two ideas were proposed by reacherjack:

The right is the same thing I proposed. I never noticed that he suggested the same thing.
The left idea is an interesting one as well. Here is where he describes it:

@davidoskky I don't know the limitations or complications involved in implementing into the app, but to me it seems like a possible solution would be to add a letter at the very top of each line.
A rough example, if there was a ñ at the tip of the line starting with "a" and "y", let the user swipe either from the top section to the right section, or from the right section to the top (both would do the same thing) and then swipe back over that same line before returning to the circle.
So: from circle through y and then to a and then back to y before returning to the circle. Or from a to y to a to circle.

Both of those ideas have pros and cons. His second (the left) idea has the benefit of

1. being able to produce TONS of diacritics
   or
2. being able to choose a direction from which to add the diacritic. You can choose whether to do a movement that starts off to the right or to the top. This may or may not result in smoother writing.

However, i prefer his first idea (the right one). Mainly because

1. It's simpler.
2. The user doesn't have to go the extra step of learning to use path 1 or path 2 depending on where they're coming from and where they're going.
3. There's less distance being traveled by your finger and it's a "lower-energy-movement". This is the main reason why I think his first idea (the right one) is the better one. It should, ultimately result in quicker typing.

@flide

1. I just wanted to mention: Regardless of what layout gets implemented, please remember that there not only is ß, a special form of s, but there's also the capitalized version of ß (ẞ). It's really uncommon actually but for the sake of completeness, it should be added, just as is the case with ä & Ä for example. https://en.wikipedia.org/wiki/Capital_%E1%BA%9E
   Also, you might want to add "ẞ" to your list of

Other characters we should think about as well :

2. Thoughts on the proposed ideas so far?

[doak]

Very good ideas here. I don't want to crash this, but I absolutely prefer the initial method brought up by @davidoskky instead of the method suggested by @Glitchy-Tozier for several reasons.

Warning, very long post approaching ... :/

First I would like to stress the most important aspects any implementation should satisfy, at least imho:

• Being fluent, i.e. don't interrupt movements. I would consider even the quick lift to enter diacritics described by @Glitchy-Tozier as disturbing the movement (It is a great idea to expand pattern space, though.)
• Don't fall into the pit to (heavily) optimise for specific languages, i.e. you should be able to write words for any language with the very same keyboard. (Don't go the same unfortunate route PC keyboard layouts did :) Shortcuts for the most used characters for the preferred language are still great and I like that idea of @Glitchy-Tozier. Let's make these available within a defined range of user defined patterns.
• Be careful with patterns which blocks (perhaps not yet for-seen) additions or tons of others gestures. Using the very first grade patterns x -> circle -> top/left/right/bottom -> circle just to attach a diacritics to the current character seems like overkill for me.

On a a little bit more abstract view, I would like to see the following concepts supported:

• Be able to insert any letter, i.e. also capital letters, digits, punctuation, special characters etc. fluently.
• Be able to make corrections (e.g. backspace or even undo/redo) fluently.
• Both points also implies that switching layouts has to be a fluent pattern.
  (Just to clarify: pressing top to toggle shift is not fluent as far as I concern. The existing method of adding a complete circular round (though long) is.)

List of possible patterns:

1. circle -> monotonous movement -> circle: character/elements of a "thing" separated by spaces (a.k.a word).
2. sector: Pole position shortcuts at word boundaries.
3. circle: There is only a single semantic which is just right: space :)
4. circle -> non-monotonous movement -> circle: Ideal for modifying current character.
5. sector -> x: A complete orthogonal dimension of patterns, which are not able to be used fluently within a word, but could start one.
6. x -> sector: Already in great use to cancel word without space and be near the to-be-typed-next pole position shortcut. But there are additional patterns possible.
7. x -> circle -> sector -> circle: Some (currently unsupported) case which would be unambiguous, though. (That was also brought up by @reacherjack422 as well as @Glitchy-Tozier.)
8. Fancy patterns like proposed by @Glitchy-Tozier (short lift etc.)

My proposal as far as I thought through it:

• Keep usual characters, space, backspace, toggle shift, return, cursor, start selection, paste, hide keyboard.
• Add consistent support for diacritics like (already available for esperanto) and proposed by @davidoskky. This is great to get any one even if you usually don't need it on your language but just want to write a foreign name for instance.
• Specify range(s) of user defined patterns. See below.
• Support fluent single backspace by _ x -> circle -> right -> circle_.
• Start fluent edit mode with x -> circle -> right -> y where ... (in fact the end of this mode is non-fluent except for single backspace)
  • ... circle inserts a single backspace.
  • ... ccw movements inserts a backspace for ever passed sector.
  • ... cw movements deletes a character on the right for every passed sector.
  • ... circle -> left -> ccw is undo.
  • ... circle -> left -> cw is redo.
  • ... circle -> top -> ccw is cursor left.
  • ... circle -> top -> cw is cursor right.
  • ... circle -> bottom -> ccw is selection left.
  • ... circle -> bottom -> cw is selection right.
• Switch layouts temporarily (i.e. for one character) with circle -> top -> cw/ccw and to locked layout circle -> bottom -> cw/ccw.
  • List of possible layouts:
    • Usual letters + important punctuation/special characters (status quo)
    • Capital letters + additional punctuation
    • Digits, special characters, toggle of modifiers (ctrl, alt, etc.)
    • More characters (even special layouts for editing would be possible)
    • Any number of user defined layouts
  • The special shortcuts _circle -> top/bottom -> circle could be used switch to two specific layouts fluently (either locked or temporary) and should be user configurable (supporting any mapping). The user could for example choose to assign the capital layout to one these shortcuts if desired, which gives a fluent way to capital characters within a word (but shorter than the existing circulation variant).

Additionally, it would be very well designed if some (extension of) patterns are defined to to be user mappable explicitly. That means all user can rely on mappings, regardless which device and which version they are currently using, but also know that a specific space is reserved for user configuration.
My idea preopose these patterns to be user configurable:

• circle -> top/bottom -> circle: Could be used e.g. as modifier for shift, diactritics, layout switching or anything else.
• _sector -> x: Any pattern which starts in a sector (including existing pattern for paste, start selection etc.)
• Perhaps even the short lift patterns (proposed by @Glitchy-Tozier) could be used as user defined.

Best regards,
doak

[flide]

You guys know what... I haven't replied to anything for last 2 days because I felt overwhelmed by the size and passion of comments you guys have been posting. Took some courage to get back to github to answer other threads. Still reading your responses... Will comment and present my current ideas in sometime.

[bbougon]

Hello,

first thank you very much for releasing 8vim, I was a big fan of 8pen at the time and was really sad it has not been maintained.
About the accented letter, if my memory works well, 8pen was working quite like @kjoetom explained (just can't remember exactly if it was an additional swipe or a pause that made the keyboard switch to additional accented letters, maybe try to install 8pen on a old phone and see how it was working).

However, great job and thank you very much @flide

[adamschmalhofer]

Armed with Wikipedia I looked at several Latin based alphabets. I was curries how many "no. of layers" different languages had. That is the maximum number of characters of a language that are based on the same standard Latin char. I added the special char for the currency if it didn't increase the "no. of layers"

Language	modified lower case chars	modified capital chars	based on chars	no. of layers
Afrikaans	èêëîïôöûü	ÈÊĚÎÏÔÖÛÜ	eeeiioouu	3
Albanian	çë	ÇË	ce	1
Breton	âêîôûùüñ	ÂÊÎÔÛÙÜÑ	aeiouuun	3
Catalan	àéèíïóòúüç	ÀÉÈÍÏÓÒÚÜÇ	aeeiioouuc	2
Czech	áčďéěíňóřšťúůýž	ÁČĎÉĚÍŇÓŘŠŤÚŮÝŽ	acdeeinorstuuyz	2
Danish	åæø	ÅÆØ	aeo	1
Dutch	ij€	IJ¢	ie	1
Esperanto	ĉĝĥĵŝŭ	ĈĜĤĴŜŬ	cghjsu	1
Faroese	áðíóúýæø	ÁÐÍÓÚÝÆØ	adiouyeo	2
Finish	åäöšž€	ÅÄÖŠŽ¢	aaosze	2
French	éàèùâêîôûëïüÿçñœæ	ÉÀÈÙÂÊÎÔÛËÏÜŸÇÑŒÆ	eaeuaeioueiuycnoa	4
Gaj (Bosnia, Croatian, Serbian)	čćđšž	ČĆĐŠŽ	ccdsz	2
German	äöü߀	ÄÖÜẞ¢	aouse	1
Hungarian	áéíóöőúüű	ÁÉÍÓÖŐÚÜŰ	aeiooouuu	3
Icelandic	áðéíóúýþæö	ÁÐÉÍÓÚÝÞÆÖ	adeiouytao	2
Irish	áéíóú	ÁÉÍÓÚ	aeiou	1
Italian	éóàèìòùî	ÉÓÀÈÌÒÙÎ	eoaeioui	2
Kashubian	ąãéëłńòóôùż	ĄÃÉËŁŃÒÓÔÙŻ	aaeelnooouz	3
Latvian	āčēģīķļņšūž	ĀČĒĢĪĶĻŅŠŪŽ	acegiklnsz	1
Lithuanian	ąčęėįšųūž	ĄČĘĖĮŠŲŪŽ	aceeisuuz	2
Montenegrin	čćđšžź	ČĆĐŠŽŹ	ccdszz	2
Norwegian	åæø	ÅÆØ	aeo	1
Polish	ąćęłńóśźż€	ĄĆĘŁŃÓŚŹŻ¢	acelnoszze	2
Portuguese	áâãàçéêèíìóôõòúù€	ÁÂÃÀÇÉÊÈÍÌÓÔÒÚÙ¢	aaaaceeeiioooouue	4
Scottish Gaelic	àèìòù	ÀÈÌÒÙ	aeiou	1
Slovak	áäčďéíĺľňóôŕšťúýž€	ÁÄČÉÍĹĽŇÓÔŔŠŤÚÝŽ¢	aaceillnoorstuyze	2
Sorbian	čćěłńóřŕšśžź	ČĆĚŁŃÓŘŔŠŚŽŹ	ccelnorrsszz	2
Spanish	áéíóúüñ€¿¡	ÁÉÍÓÚÜÑ¢	aeiouune?!	2
Swedish	åäö	ÅÄÖ	aao	2
Turkish	çğıiöşü₺	ÇĞIİÖŞÜ	cgiiosul	2

Currently the 8VIM keyboard offers the Esperanto characters. Of the 30 languages I looked at 9 of them only have one additional "layer" (one of those being Esperanto) and no language had more then 4 layers (Portuguese and French).

[davidoskky]

This looks exactly the same way I proposed sometime ago: #65 (comment)
If you read the subsequent messages you can find some arguments in favor and against this methodology.
I do believe this is the best proposed method, if we cannot follow the first idea by @reacherjack422 due to other limitations.

[adamschmalhofer]

Well, if I understand that comment correctly there were multiple going back and forth for the diacritics in the previous suggestion. E.g.:

à: (center) right, top, right, top, left, center

That is different than what I suggest. I suggest diacritics to always have exactly one directional change between anticlock- and clockwise.

so for a being:

a: center -> right -> top -> center
layer 1 diacritics on "a" would be

center -> right -> top -> right -> center

and layer 2:

center -> right -> top -> right -> bottom -> center

layer 3:

center -> right -> top -> right -> bottom -> left -> center

layer 4:

center -> right -> top -> right -> bottom -> left -> top -> center

and so on.

[kjoetom]

@adamschmalhofer
Out of curiosity I just had to test your 8vim layout with german diacritics tonight and not later in the week. And it works really well. If you draw a small circle on the sector boundary line instead of moving forward-backward-forward, the input gets also really smooth.

I have an alternative suggestion, e.g. for the input of the umlaut u (ü): perhaps it would be easier to perform the forward-backward-forward movement already at the first sector boundary and not at the last one, because the first one is easier to locate in my opinion.

All in all, however, it's a welcome step towards german 8vim layout. Thank you.

[adamschmalhofer]

@kjoetom Nice to hear :-). I'll configure your suggestion, so we can all play with and test it. To make sure I understand it correctly could you please verify that I got it correctly:

"a" without diacritic	"ä" german-kjoetom	"ä" german-1	"ä" german-2
center -> right -> top -> center	center -> right -> bottom -> right -> top -> center	center -> right -> top -> right -> top -> center	center -> right -> top -> right -> center

[kjoetom]

No, I did not express myself precisely. For letters from layer 1 I would leave the "german-1" method unchanged.

Only for letters from layers 2-4 I would possibly proceed differently:

Example: "ü"

("u" without diacritic)
center -> bottom -> right -> top -> center

("ü" german-1)
center -> bottom -> right -> top -> right -> top -> center

("ü" german-kjoetom)
center -> bottom -> right -> bottom -> right -> top -> center

To put it in a picture, this way it would be like circling the base letter "u" once to make it a diacritical letter.

---

Based on my switch mode idea I would also suggest another variation. We could also switch to a diacritic character mode (center -> top -> center) before writing the basic letter.

for "ü" this would be:

("ü" german-kjoetom-2)
center -> top -> center -> bottom -> right -> top -> center

[flide]

Actually, this seems like a great idea, I can at-least implement the "single layer" languages like esperanto while we figure out an "all encompassing" solution. Thanks for the list.

…

On Sat, May 22, 2021 at 6:53 PM Adam Schmalhofer ***@***.***> wrote: Armed with Wikipedia I looked at several Latin based alphabets. I was curries how many "no. of layers" different languages had. That is the maximum number of characters of a language that are based on the same standard Latin char. I added the special char for the currency if it didn't increase the "no. of layers" Language modified lower case chars modified capital chars based on chars no. of layers Albanian çë ÇË ce 1 Afrikaans èêëîïôöûü ÈÊĚÎÏÔÖÛÜ eeeiioouu 3 Czech áčďéěíňóřšťúůýž ÁČĎÉĚÍŇÓŘŠŤÚŮÝŽ acdeeinorstuuyz 2 Danish åæø ÅÆØ aeo 1 Dutch ij€ IJ¢ ie 1 Esperanto ĉĝĥĵŝŭ ĈĜĤĴŜŬ cghjsu 1 Finish åäöšž€ ÅÄÖŠŽ¢ aaosze 2 French éàèùâêîôûëïüÿçñœæ ÉÀÈÙÂÊÎÔÛËÏÜŸÇÑŒÆ eaeuaeioueiuycnoa 4 German äöü߀ ÄÖÜẞ¢ aouse 1 Hungarian áéíóöőúüű ÁÉÍÓÖŐÚÜŰ aeiooouuu 3 Irish áéíóú ÁÉÍÓÚ aeiou 1 Icelandic áðéíóúýþæö ÁÐÉÍÓÚÝÞÆÖ adeiouytao 2 Italian éóàèìòùî ÉÓÀÈÌÒÙÎ aceeisuuz 2 Lithuanian ąčęėįšųūž ĄČĘĖĮŠŲŪŽ aceeisuuz 2 Norwegian åæø ÅÆØ aeo 1 Polish ąćęłńóśźż€ ĄĆĘŁŃÓŚŹŻ¢ acelnoszze 2 Portuguese áâãàçéêèíìóôõòúù€ ÁÂÃÀÇÉÊÈÍÌÓÔÒÚÙ¢ aaaaceeeiioooouue 4 Spanish ñ€¿¡ Ñ¢ ne?! 1 Swedish åäö ÅÄÖ aao 2 Turkish çğıiöşü₺ ÇĞIİÖŞÜ cgiiosul 2 Currently the 8VIM keyboard offers the Esperanto characters. Of the 20 languages I looked at 8 of them only have one additional "layer" (one of those being Esperanto) and no language had more then 4 layers (Portuguese and French). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABX5WRZTA5UNHF2ESNG4WL3TO6V37ANCNFSM4UVO3NTA> .

[adamschmalhofer]

@kjoetom , @Glitchy-Tozier I created a 8vim with german diacritics. If you want to try it out: https://github.com/adamschmalhofer/8VIM/releases/tag/german-1

[Glitchy-Tozier]

@adamschmalhofer If you want to create a good german layout, I suggest using this layout #144 (comment) (the last one) instead of the default english layout. :)

(EDIT: You could use @sslater11 's script to create a layout-file I think)

[kjoetom]

@adamschmalhofer
I'm looking forward to doing that. I hope I can fit it in over the next few days. I will then give feedback here.

The missing german diacritic letters are the main reason, why I could not use 8vim in daily live.

If you're interested, I've proposed a new feature that would allow you to write (among other things) the 7 most commonly used diacritic letters with two short movements. See image "Writing a predefined main diacritic letter" here. But that's probably not so easy to implement.

[adamschmalhofer]

@Glitchy-Tozier I'll have a look at extending this script to include the diacritics. Then I'll add your German layout.

@kjoetom I'm afraid that is way out of the scope of what I am currently willing and capable of doing. What I could do however is using the multilayered method we use for Spanish to offer a variation that has all diacritics. We would still have to agree on which order the á à â ä æ... should be in.

[kjoetom]

Well, I admit that the "switch mode" method is probably too complicated.

I kind of had the idea, instead of many different localized layouts, to have one layout that fits all languages with Latin characters and does not include diacriticals, but makes all diacritical letters relatively easy to reach and can be optimized according to one's needs.

[adamschmalhofer]

I've created a version with the french diacritics with each of the four suggested variations of entering them under: https://github.com/adamschmalhofer/8VIM/releases/tag/french-4 So we can try out the different methods.

[flide]

Hi All,

With the help of @adamschmalhofer 's contribution, I have been able to setup a framework for adding layouts easily.

To add a new layout following needs to be done:

Develop a keyboard-data xml file.
Name the file with following format [{language-iso-code}_{font-code}_{layout-name}]
Place the file in the raw folder

Language code is the 2 character code for the language as per ISO standard
Font code is one of the following strings, and as of now only "regular" is going to function properly : "regular", "bold", "italic", "underline"
Layout name is the display name of the layout

In the settings menu the layout would be presented as "Layout name (Language)"

The characters for the layout are now part of the keyboard-data file itself.
Please check the "he_regular_hebrew" file in the raw folder for reference.

I will request all to open one PR per layout.

[fsbox666]

Hello flide, first of all : EXCELLENT tool you made there... very impressive thinking and putting it into practice. Thanks for developing it... Being at an "intermediate" level (using French, German and English), I am not sure I understand if the feature is implemented in the standard app (mine is downloaded from the /e/OS "App store")? When I click on the diactirics setting, there are no choices available (does it depend on the system language?) or is that a bug? If it's not completely implemented and needs some manual installation, would it be useful to post a small "how to" explanation here for those who feel comfortable enough to install adamschmalhofer's and your files? Thanks :-) All the best and again congratulations, Felix

[adamschmalhofer]

#238

[fsbox666]

Great, thanks a lot and sorry I had not seen the bug report ! (To add to the detail, it's on a fairphone 4)

So I managed for the French file and also got through the "downloaded empty file" issue ;-) ... but cannot seem to make the diacritics appear. I am not sure I understand clearly from the above discussion which is the currently used method for actually making the diacritics appear.

It might be worth posting it in this thread again for the novice:

• back-and-forth movement across a line before the character movement?
• back-and-forth movement across a line after the character movement and then back to centre?
• other?

Sorry if it's me not getting it...

All the best, Felix

[adamschmalhofer]

As you know Center -> Bottom -> Left -> Center enters an "e". To enter the "é" do Center -> Bottom -> Left -> Bottom -> Center. OTOH "è" is Center -> Bottom -> Left -> Bottom -> Right -> Center and "ê" is Center -> Bottom -> Left -> Bottom -> Right -> Top -> Center. Hope that helps.

Regards from an other /e/ Fairphone user (Fairphone 3).

[fsbox666]

EXCELLENT. Works. Wow. Thanks for this fabulous work.

Regards from my wife who's the user ;-) ... !

[ghost]

Hey, here is another happy /e/ Fairphone 3 user who enjoys swiping his german ümlauts 🙃 Thanks for this great keyboard!
(swiped with 8vim)

[kjoetom]

Hello all,

I tried to extend the regular german layout and would like to make it available here for testing and discussion.
It includes in principle the following extensions/changes:

• Capital letters - alternative method of input
• Diacritical letters - extension and a more comprehensive alternative
• Greek letters

de_modified_german_220209.xml.zip

An explanation of how to use the layout can be found in my next 3 comments below.

[doak]

Btw, I have reverted my keyboard to iteration-8 to be able to play with CIRCLE → TOP → CIRCLE etc. ^^

[doak]

Mh, I guess I did f.cked-up the strokes for Omega etc., I have missed the last backward. Sorry for that :(
I will have a look the next days.

Omega is accessible currently with:
CIRCLE → TOP → RIGHT → BOTTOM → RIGHT → BOTTOM → LEFT → TOP → CIRCLE
Correct, according to your concept, is
CIRCLE → TOP → RIGHT → BOTTOM → RIGHT → BOTTOM → LEFT → TOP → LEFT → CIRCLE,
isn't it, @kjoetom?

[doak]

CIRCLE - TOP - CIRCLE - TOP - CIRCLE - Letter - TOP - lift finger (for capital letters)

Mh… I also changed (non intentionally) the way you insert the capitalised set of diacritics. Capitalisation works the same as for the original letter, hence it is like this:

• My current layout:
  CIRCLE → TOP → CIRCLE → (capitalised) letter → TOP → lift finger (for both, lower- and uppercase letters)

• @kjoetom's concept:
  CIRCLE → TOP → CIRCLE → letter → TOP → lift finger (for lowercase letters)
  CIRCLE → TOP → CIRCLE → TOP → CIRCLE → letter → TOP → lift finger (for uppercase letters)

Imho this is even better. @kjoetom, please let me know if you agree. If not, I will fix it to match your concept.

[doak]

Mh, I guess I did f.cked-up the strokes for Omega etc., I have missed the last backward. Sorry for that :(

I thought about it a little. Should I really change it or are you fine with that, @kjoetom?

• My layout for letter Omega:
  CIRCLE → letter → (back → forward) → forward → forward → CIRCLE (lowercase Omega)
  CIRCLE → letter → (back → forward) → forward → forward → (back → forward) → CIRCLE (uppercase Omega)
• @kjoetom's concept for letter Omega:
  CIRCLE → letter → (back → forward) → forward → forward → back → CIRCLE (lowercase Omega)
  (uppercase not assigned yet)

[kjoetom]

Great, thank you @doak.

I'll try to summarize your questions from the 5 posts above and add my comments/answers.

CAPITAL LETTERS

That you have now included both variations to enter the capital letters of the basal language layout without using the shift function, I think is great - thank you.

AS FOR YOUR FIXMEs:

I think your comments are all correct. I don't know where the missing diacritical letters got lost (I had them included in my "de_modified_german_220209.xml" test layout). If we want to sort the i-diacritics by the number of languages they are used in, the order should be:

Languages	171	152	61	57	44	41	39	8	4	4	4	3	2	2	1	1
small	i	í	î	ī	ì	ï	ı	ɪ	ĩ	į	ị	ǐ	ĭ	ɨ	ij	ỉ
capital	I	Í	Î	Ī	Ì	Ï	I		Ĩ	Į	Ị	Ǐ	Ĭ	Ɨ	IJ	Ỉ

But that is not so important.

CIRCLE-TOP-CIRCLE AND SETS OF DIACRITICAL MARKS

We have to be careful not to mess up the basic concept of @flide and disturb possible future developments.
I've thought of another gesture we could use instead that also works in iteration 9 (as just tested).

E.g., for c-related letters with diacritics ABOVE this would be

NO_TOUCH;TOP;INSIDE_CIRCLE;TOP;INSIDE_CIRCLE; LEFT;BOTTOM;RIGHT;INSIDE_CIRCLE; TOP;NO_TOUCH;
instead of
INSIDE_CIRCLE;TOP;INSIDE_CIRCLE; LEFT;BOTTOM;RIGHT;INSIDE_CIRCLE; TOP;NO_TOUCH;

So we would have to start in the Top-Sector before doing the C-T-C movement. You can test it in this modified German layout: kjoetom-with-german-base-layer_N-T-C-T-C.xml.tar.gz
What do you think about that?

[EDIT: My first attempt replacing "C-T-C-SectorOfLatinLetter-..." by just starting in the "SectorOfLatinLetter-..." seemingly was conflicting with special_core_gestures.xml and therefore didnt work for all letters]

Btw this does not fix the fact that 8VIM currently refuses to input more than one capital character at a time.

GREEK LETTERS (MORE THAN 1 BEING ASSOCIATED TO 1 LATIN LETTER)

This concerns the following: η Η ω Ω ψ Ψ ς Σ θ Θ
My thought was to realize all Greek letters assiciated to a certain latin letter by using the same sector, to keep the following sector free for other sets (e.g. Cyrillic letters). So if a certain Latin letter has more than 1 Greek letter assigned to it, this concept would only be maintainable with my variant (forward to next sector and back again). But as long as there are no more letter sets, there is no need to stick to this.

Language layouts in general

I think it's great that layouts can now be adapted quickly with your generator (incl. diacritic letters). By the way, I'm currently working on a more objective scoring system for layouts, which I will discuss here if it turns out to be useful (I'm not sure yet). You can find it here. So the final optimal layouts might still change a bit.

I hope I addressed all your points from above and didn't miss any.

kjoe ;-)

[kjoetom]

Capital letters

In the regular german layout, besides using the caps key, you can also write uppercase letters by additionally swiping 360 degrees before finally entering the circle.

I have changed this in the modified layout. Instead of swiping 360 degrees, you move your finger one sector back and then forward again before returning to the circle. This works for all regular letters and all single diacritical letters.

To write i.e. the capital letter "U" without using the caps-button, do:
CIRCLE - BOTTOM - RIGHT - TOP - one sector back - then forward again - CIRCLE

[doak]

Just to point put that "one sector back - then forward again" is a very handsome small circle at the sector line.

[kjoetom]

I think so too. I got used to it right away. The additional 360 degree movement was very confusing for me when it came to letters from layer 3 and 4.

[kjoetom]

On the other hand, I think why not implement both options in parallel. The 360 degree variant is perhaps better suited for users of cell phones with small displays.

[kjoetom]

Diacritic letters

I have now added all diacritical characters of those 30 languages that @adamschmalhofer mentioned in his comment above.
Diacritical characters that are relevant for the German language I have kept in front and all others I have added depending on the number of languages in which they are used.

For example, to write an "ô" character, do

---

Unfortunately, the following way to even more diacritical characters, which I implemented in my test layout, does not work in 8vim iteration 10 anymore, because probably the CIRCLE - TOP - CIRCLE gesture is no longer available as a toggle.

Sometimes, however, one needs very rarely occurring diacritical characters (e.g. when writing a foreign name). To have additional diacritical characters at hand, I implemented all diacritical characters I could find in 171 languages using latin characters as follows.

To get all variants of a given letter with diacritical marks ABOVE this letter, write:
CIRCLE - TOP - CIRCLE - Letter - TOP - lift finger (for small letters) and
CIRCLE - TOP - CIRCLE - TOP - CIRCLE - Letter - TOP - lift finger (for capital letters)

For variants with diacritical marks BELOW a letter:
CIRCLE - TOP - CIRCLE - Letter - BOTTOM - lift finger (for small letters) and
CIRCLE - TOP - CIRCLE - TOP - CIRCLE - Letter - BOTTOM - lift finger (for capital letters)

And for all other variants (including multiple diacritical marks) and related letters:
CIRCLE - TOP - CIRCLE - Letter - RIGHT - lift finger (for small letters) and
CIRCLE - TOP - CIRCLE - TOP - CIRCLE - Letter - RIGHT - lift finger (for capital letters)

I know, the approach is not very elegant, because you have to delete all superfluous letters manually. But at least you can get rarely used diacritical letters.

[doak]

Unfortunately it does not work for me.

@kjoetom, it may be that this layout can't be loaded dynamically (with the existing menu option), but needs to be installed with the application.

[kjoetom]

To load the layout, you must first unzip it and save it on the cell phone. After that you can load it in the settings of 8vim via "Select layout file from device".

[kjoetom]

Unfortunately, we can currently only change the layouts via the settings, which completely interrupts the writing flow. If we could do this via a toggle movement, it would open up many new possibilities. E.g. we could place all Greek letters in their own easily accessible layout.

[doak]

Okay, loading via settings work for you.

Unfortunately, the following way to even more diacritical characters, which I implemented in my test layout, does not work in 8vim iteration 10 anymore,

I just read this sentence, which I seem to have overlooked. Since there is no iteration-10, I guess you meant iteration-9. That release already included a change to be less annoying if you make errors (which imho is very useful as long as you are no an 8vim expert, which I am not :) and that most likely conflicts with the used CIRCLE → TOP → CIRCLE stroke.
I guess you refer to that, aren't you?

[kjoetom]

This is probably because I added the sentence later, when I noticed that after my last 8vim update the additional diacritical letters didn't work anymore. You are right, it is iteration-9 (and I had iteration-8 before). I'm going to change this right now.

[kjoetom]

Greek letters

Since I sometimes also need single Greek letters, I have integrated them for test purposes also in the modified layout. They are located 1 sector after the Latin capital letter (the variant created without the caps button).

To write the greek capital letters, you have to press the caps-button before.

For example, to write a lowercase "omicron" assigned to the Latin letter "o", do:
CIRCLE - BOTTOM - RIGHT - one sector back - then forward again - NEXT SECTOR - CIRCLE

Unfortunately, a second Greek letter is also assigned to the Latin letter "o" - the "omega". To write such a further Greek letter nevertheless, I use a "short trip" to the following sector and back again:

So, to write a lowercase "omega" also assigned to the Latin letter "o", do:
CIRCLE - BOTTOM - RIGHT - one sector back - then forward again - NEXT SECTOR - one sector forward - then back again - CIRCLE

Ok - hit me, but i just didn't have a better idea how to implement this. Mainly because I want to keep the next sector free for e.g. cyrillic characters.

[doak]

It has to be my machine. Neither omicron nor omega works for me, though I get a o for omicron.
(Having said that, my Android is quite outdated (Replicant 6). Perhaps that is the reason.)

Anyway, all other diacritical seem to work. Thanks!

[kjoetom]

Well, maybe this is due to the fact that the "omicron" looks identical to the latin letter "o". But for the "omega" this should not be the problem.

Did you do it the way indicated below?

For omicron

... and for omega

[doak]

@kjoetom, thanks a lot for the pictures!
In fact I did it wrong, i.e. it work like you sketched above.

[doak]

I guess I was confused by "NEXT SECTOR" and "one sector forward".

[kjoetom]

Glad to hear it's working.

By the way: the "NEXT SECTOR" concept could also be implemented for the diacritical letters, e.g. if there are more than 4 for a certain letter in a language. So up to 8 diacritical letters or special characters could be implemented in a language specific layout.

[flide]

I think this is a feature worth developing.

…

On Sat, 19 Feb 2022, 04:23 kjoetom, ***@***.***> wrote: Unfortunately, we can currently only change the layouts via the settings, which completely interrupts the writing flow. If we could do this via a toggle movement, it would open up many new possibilities. E.g. we could place all Greek letters in their own easily accessible layout. — Reply to this email directly, view it on GitHub <#65 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABX5WR7IMB6EQMNZ5LTZFI3U33EXRANCNFSM4UVO3NTA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JapanYoshi]

I think, if we're going this route, we could greatly benefit from a letter preview pop-up that updates every time the cursor enters a different sector.

e.g. typing "f" makes the pop-up go through these phases:

• tap on center: pop-up stays hidden
• drag right: pop-up appears and says “→”
• drag to bottom quadrant: “n”
• drag to left quadrant: “m”
• drag to top quadrant: “f”
• drag to center: pop-up disappears

[Paperweb]

Yes ! I was going to look for another thread on that topic.

I believe that the learning curve would be so much less steep if one could visualize in an instant what glyph is actually "in cache".

I thought that it could simply be highlighted (bold, color, others fade out), actually a bit like in the presentation video, but a micro popup or fixed location on the screen would make more sense.

In that vein, the sections could update as the swipe pattern changes.

So in principle :

circle
→ bottom [highlights bottom sector, fades others]
→ left [highlights e, and/or displays it somewhere]
→ bottom [all sectors replaced by diacritics, highlights/displays first variant (é)]
→ [...]
→ circle [enters diacritic, reset sectors, display empty]

---

@flide is it complicated to allow the dynamic update of sectors while gesturing ? And to allow individual highlighting of glyphs ?

[flide]

never thought about it, don't really know

…

On Thu, 17 Mar 2022, 00:02 Paperweb, ***@***.***> wrote: Yes ! I was going to look for another thread on that topic. I believe that the learning curve would be so much less steep if one could visualize in an instant what glyph is actually "in cache". I thought that it could simply be highlighted (bold, color, others fade out), actually a bit like in the presentation video <https://youtu.be/99vsUF4NuLk?t=170>, but a micro popup or fixed location on the screen would make more sense. In that vein, the sections could update as the swipe pattern changes. So in principle : circle → bottom [highlights bottom sector, fades others] → left [highlights *e*] → bottom [all sectors replaced by diacritics, highlights first variant (f.e *é*)] → etc → circle [enters diacritic, reset display] ------------------------------ @flide <https://github.com/flide> is it complicated to allow the dynamic update of sectors while gesturing ? And to allow individual highlighting of glyphs ? — Reply to this email directly, view it on GitHub <#65 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABX5WR5NUPXJBIW7HMZIIW3VAISMTANCNFSM4UVO3NTA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Paperweb]

Actually both [dynamic update of sectors] and [preview current glyph] are discussed in #241
There is obviously a link to be made with this discussion about diacritics input.

[kjoetom]

Hi @doak,
are you still in this discussion?
I tried to convert 2 new layouts to xml files with your generator to test them in 8vim.
Unfortunately I did not get the program to run and kept getting error messages. I have tried python and pypy3.

I may have done something wrong with the input file (these are attached below).
2-german-layouts.zip

If you are interested, you can have a look at them here: #90 (comment)

[kjoetom]

I finally did it, but only by using 8vim-layout-generator-dev2. Also I had to modify and rename the configuration files to "kjoetom-with-german-base-layer.8vim" to not get an error message.

Here they are:
kjoetom-1-german-base-layer.8vim.zip
kjoetom-3-german-base-layer.8vim.zip

[Inserting bunch of diacritics did not work at first, but this is not so important (this is because the "INSIDE_CIRCLE;TOP;INSIDE_CIRCLE" is blocked now by the file "zero_turn_no_actions.xml"). I fixed this by omitting the first part "INSIDE_CIRCLE;"]

German umlauts + additional diacritics as well as Greek letters are working well. Also the gesture for capitlizing a Letter is functional. You can get the layouts here: #90 (comment)

Thank you @doak and @Glitchy-Tozier for the programs you provided, without which I could not have done these layouts or only with enormous efforts.

kjoe

[doak]

Hey @kjoetom,

I am sorry, I moved away. But if I find some time, I am happy to bring the layout generator into shape again. I vaguely remember that I refactored it a lot and did not finish it :/
Do you mind to contact me via e-mail?

Regards,
doak

[kjoetom]

@doak Don't worry about it. I have found a workaround and don't want you to put extra work into it. At least not for me. ;-)

Sorry for my late response and thank you for answering.

kjoe

[doak]

I can't promise much, but I really appreciate your effort in pushing this topic forward. Don't hesitate to give me a ping if you need the generator in shape to support you. (The worst which could happen is that I don't have time.)