On 29/05/18 11:19, Ancor Gonzalez Sosa wrote:
On 05/23/2018 10:32 PM, Joaquín wrote:
Hi all,
Hi thanks for your reply. How was the openSUSE Conference 2018? I hope
you have had a good time :)
Hi. First of all, let me apologize for the huge delay in the reply. The
whole YaST Team at SUSE was first in a Team Workshop at the SUSE
Headquarters at Prague and then in the openSUSE Conference 2018. So not
much time to take care of the mailing list.
I am Joaquín and I am working on a rewrite of YaST keyboard module, info
here [1]. In a nutshell, I am writing a keyboard module for YaST with
ruby using OOD, with an implementation for SystemD.
Right now i am looking to map the code of every keyboard layout (for
example: us, es, us-dvorak) with their human readable translation (
“English (US)”, “Spanish”,...), but i have some questions about it.
I have taken a look to the existing code to try to use the same
translations. And i found two files, “keyboard_raw_opensuse.ycp” and
“keyboard_raw.ycp”. Also i found the part of the code that is using one
of these two files [2]. The only difference between these files i see,
is that in some cases, for a language one file uses a .map.gz file and
the other use a different .map.gz, for example with “spanish-lat” see
[3] and [4].
I think that with only one map for each code is enough for an
implementation with SystemD but i am not sure, because I don’t
understand the reason of these differences in the current module. It
would be nice if some of you can explain to me so i can understand it,
and apply a good solution in the project.
The reason is that openSUSE was migrated to a different set of console
fonts and keyboard mappings before SLE did the same transition. At some
point we needed to keep the old conservative fonts and keyboard maps for
SLE and to offer new ones for openSUSE. We introduced the change here.
https://github.com/yast/yast-country/pull/104
That was just a transition period. At a later point in time, the console
fonts were re-unified.
https://github.com/yast/yast-country/pull/161
Not sure why the keymaps were not re-unified in the same way. But now
that SLE and openSUSE Leap are closer than ever, I can't see a reason
for them to diverge again.
Also in the case that is only needed one mapping, which of those files
should i take as reference?
I would go for keyboard_raw. And just in case you have not done it
already, please migrate it to a sane format like Yaml containing only
the information that is still relevant nowadays.
As you suggested, I migrated the layouts information to a yaml file. But
I found that there are some layouts in the keyboard_raw that does not
appear when executing "localectl list-keymaps" or "localectl
list-x11-keymap-layouts", so i think that do not exist. Exactly are this:
khmer.map.gz
korean.map.gz
arabic.map.gz
taiwanese.map.gz
chinese.map.gz
I migrated that ones too, but right now in the new module these layouts
does not appear in the lists that is shown to the user. Is this what is
supposed that should happen?
Also I found that in keyboard_raw file "Portuguese (Brazil -- US
accents)" and "US International" use the same layout
"us-acentos.map.gz". Is this ok? Should both of them appear to the user
or it is enough with one of them?
Additionally I have been looking a way to implement the “Expert
settings”. That expert settings are repeat rate and delay, numlock
on/off and disable/enable caps Lock. But i found that systemd-localed
does not manage that, so i suppose that the idea is to do it in the same
that in the current module. As i can see in the code, to manage that
values only is needed to write the values in “/etc/sysconfig/keyboard”,
I am right?
Thank you all,
Joaquín
Thank you for the great work.
Thanks for your help.
[1] https://github.com/openSUSE/mentoring/issues/79
[2]
https://github.com/yast/yast-country/blob/master/keyboard/src/modules/Keyboard.rb#L1421
[3]https://github.com/yast/yast-country/blob/master/keyboard/src/data/keyboard_raw_opensuse.ycp#L167
[4]https://github.com/yast/yast-country/blob/master/keyboard/src/data/keyboard_raw.ycp#L168
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
