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.
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?
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.
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
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 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.
This doesn’t solve the problem, 64bit apps and libraries will also crash and need to be recompiled in exactly the same way. So we need to do this work for both versions of Haiku (and that comes for free, if you do it correctly on one it works on the other)
The way the add-on for media keys currently works will be broken by the changes to properly support them.
It only happens to work currently because the hid driver forwards essentially raw usb keycodes to userspace for keys that can’t be mapped by the current keymap structure. As a result the add-on can intercept those. But this can only work for USB, not ACPI and other way to have these keys (unless the respective drivers convert their keycodes in some way to fake the usb ones?). So, it will need some updates when this work is done, at least.
Hi, yes, I have done some research, I know how I can fix usb hid driver to send media keys and I am aware there are several patches pending for a keymap fix.
I did yesterday a try for get_key_map function following your instructions but I had no luck. I haven’t find a way to both keep binary and API compatibility. Perhaps I will submit the patch tonight just for discuss the problem on top of some real code.
This is a topic I really don’t master at all (and don’t enjoy) but it is being a bottleneck for lots of incoming fixes and features.
