Time past, and my conclusion: Haiku needs greekboy’s patches for more deadkeys. Linux and Windows support more deadkeys.
“Must have” deadkeys:
dead_abovedot
dead_abovering
dead_acute
dead_belowdot
dead_breve
dead_caron
dead_cedilla
dead_circumflex
dead_diaeresis
dead_doubleacute
dead_grave
dead_hook
dead_horn
dead_macron
dead_ogonek
dead_tilde
In other words, keymap in Haiku must have the same capabilities as in Linux or Windows or Macos (OSX). Keymaps must work in the same way across all OSes. This is like standard de facto. And only additional things can be implemented with input methods.
If I write ‘ī’ in “vīras” with dead_macron key in Windows and Linux: I must have opportunity to do that in Haiku too.
We still can’t change this without breaking BeOS compatibility, unless:
So, we can’t just merge the patch as-is.
I have a solution for the problem: Haiku can have new API keymap and for older BeOS apps this keymap must be seen trough some special input method.
Could this be done only for 64 bit platform? BeOS compatibility shouldn’t play into it, so not a concern.
Please elaborate if I’m mistaken in my assumption.
Well, it could be done on both 32 and 64bit as long as we can provide some fallback for the old BeOS apps. We did the same for get_system_info, for example, when we removed the limit of 8 CPUs. BeOS apps will only see the first 8 CPUs, newly built apps will see all of them. We could do the same for dead keys.
However, I don’t see if this is an improvement over the input method based solution. Not being a greek typer myself, I can easily miss somethng here, but I would expect the input method to give at least as good, if not better, results.
Then there is the question of integration with the OS. If the input method works well, then we should probably make it available in the default image, and enable it automatically if you select a greek keyboard?
XDK input method not work for me anyway, actually I not able to test tested it (I do not know what is wrong). I use my own non standard keymap layout across linux, windows and haiku (also I intend to make one for macos), and only in haiku keymap is invalid – without some dead keys. You can try to replace those dead keys by some input of diacritic, but only for yourself, it will differ with input in another OS. For example dead_macron is neaded for latin, and latin is used across the world. Additional dead keys is needed for many languages, not only for greek.
Just illustration how looks dead keys (highlighted) in my keymap through different OSes
Windows:
MacOS:
Linux:
Haiku:
Any news after 4 years on enhancement of Haiku keymaps? Will we have in Haiku more dead keys and more entries for characters? This problem will not go away. It will only become more relevant. Or not?
Labas,
Language-specific features are generally interesting to developers that speak the said language, and therefore on a low-priority list for the developers that do not speak the languages. It might be a worthy effort to contact members of the Lithuanian community and ask for help (forums, communities etc.).
Aside from Vietnamese, I do not think an input method should be needed for Latin-alphabet using language. As someone, who is working with multiple scripts each day, I am all for Haiku getting more love on i18n front.
Sveikas,
Everything is already done, by greekboy years ago:
https://dev.haiku-os.org/ticket/9744
But there is no willingness for only English-speaking people to accept those changes. They think it doesn’t matter so much. Of course, in the case of the Lithuanian language, those changes will be needed only by some professionals. But in the near future, desktops and laptops will be used exclusively only by professionals, everyone else will be satisfied with tablets and phones. So Haiku has to focus on professionals. I think so.
While it may be so, it is clear that the code is not up to Haiku coding standards. But still, this is good news, it means that the amount of work needed is rather trivial.
Seeing as most Haiku developers are european I don’t think this holds much truth. Anyhow, @PulkoMandy Answered in the ticket why it was not merged.
I have marked the patches as obsolete for the reasons mentionned above. If I understand things correctly, this is not needed to type "modern" greek. I would suggest writing a dedicated input method rather than extending the keymap system in such non-compatible way.
You can now use http://haiku.healynet.org/xdk.html to get custom keymaps. Relevant discussion: https://discuss.haiku-os.org/t/keymap-and-new-dead-keys/4454
The patches above would make the keymap format much more complicated for /every/ language, yes it probably needs to be extended. The patch was not accepted because it was deemed to not be the correct solution, not because devs don’t care.
EDIT: It seems this specific patch series was already discussed in the thread above, so that confuses me even more where this statement comes from.
The following change would suffice the Lithuanian language alone: at least 34 inputs for each dead_key (for uppercase and lowercase letters, 17+17).
For other languages maybe useful: 5 user-defined dead_keys (not predefined in Haiku), so user (keymap) can for example choose cedilla or macron dead_key.
The main reason the change from greekboy has not been merged is not lack of interest or disdain for internationalisation. Please stop attacking us on made up reasons.
The reason it has not been merged is that it changes the keymap structure which is part of the public API. This will break keyboard handling in any app that uses the get_key_map function and make such apps crash.
We have discussed this and greekboy never updated his patch to fix the problem.
More recently we have hit the same problem with a patch to add media keys support. The same thing happened: the patch was reviewed, it was breaking this API in the same way with the same consequences, I explained again how to fix it, no one did. So the patch was never merged. I did not do it myself because I have a thousand things in my todo list and it keeps growing. I just can’t do everything here. The situation is similar for other developers. Also there is some lack of knowledge involved. To review the greek polytonic patch, I had to research and learn about the greek alphabet, how it is typed on other operating systems, what the polytonic variant is, etc. I would not be the right person to do this, I will probably get it wrong and then people will call me stupid and incompetent again.
I’m all for better i18n handling, but not at the cost of making applications crash. I hope you can understand that.
Now it would be great if the people working on these two changes could coordinate their efforts, so that we only have to introduce a v2 keymap structure. Not a v2 and then a v3 a few weeks later.
I think currently @Lt_Henry is investigating the media keys one
Sorry. But Haiku just need to increase the number of possible records for dead_key. Would this be problematic for the system?
The problem is that it is not “just”.
Anyhow, I was the one who investigated media keys 2ish years ago, but never finished the patch series (mostly because of my inexperience with the codebase then)
I’m happy to work with whomever is working on it now, but personally I don’t think adding countless dead keys into the format for every language is the best option. It seems like the wrong mechanism for this.
There is no need for countless dead keys.
Only for this:
Will there be problem to implement this?
Yes, it is a problem.
There is a get_key_map function that apps can call to get the keymap.
When you “just” add some things to the keymap structure, it becomes larger.
The apps that were compiled before the change do not know about this. They allocate a too small buffer. When they call the function, there is a buffer overflow, overwriting other things in the application memory. This will likely sresult in crashes or other strange bugs.
So, the function must be modified, so that when an old app calls it, it makes sure to return a keymap in the older format, and not overwrite anything. The app will not get the full information but at least it will not crash.
We can then introduce a new function to get the full keymap in the new format, and recompiled applications can use that.
Of course if it was so easy as to just change the size of an array, that is a two minute work and it would be done for years already. But it is not.
