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

Other characters we should think about as well :

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

Seems like most are modifying vowels.

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: äöüÄÖÜß

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)

@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.

@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...

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.

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 ( क -> कू, त -> त्)

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

@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!

@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)

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?

@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.

@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?

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

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.

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

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.

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.

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.