Here is a symbols/ files for adding braille patterns bindings to the keyboard, for use with the following new options: braille Adding braille patterns to certain keys braille:home_row Add braille patterns to the home row braille:left_hand Add braille patterns to the left hand braille:right_hand Add braille patterns to the right hand braille:keypad Add braille patterns to the keypad
Created attachment 10426 [details] XKB symbols for braille
Mmm, that said, maybe it should rather be implemented as a whole group?
Created attachment 10427 [details] XKB group for braille That's much simpler indeed :)
I like the last version. I'll use it. But I need a bit more context info. Is Braille international? Does it depend on country/language?
More questions: 1. Would it make sense to put all these symbols into one xkb_symbols? Why do you want them split - would anyone use one part without using the rest? 2. In terms of layouts/variants/options - would it be more logical to expose this group as an XKB layout or as an XKB option?
Yes, braille depends on the language, the country, the culture, whether contraction is in use or not... and even personnal preference. That's why xkb can't handle all that itself and should just produce the 0xfff[1-a] keysyms corresponding to the ten dots. The actual translation is then performed by an X Input Method. By default, libX11 produces raw braille patterns (U+28xy), which is already useful for writing UTF-8 braille tables for instance. Later on, I'll write a more advanced Input Method in a separate program that will take into account language/country/culture/contraction/personnal preference.
About splitting: home_row, left_hand and right_hand conflict. The numpad would doesn't conflict with others, however, so it may make sense to include it in all others. About layout vs option, I haven't seen an option that defines a whole group, so I thought using a layout was the finest way. And to me it makes sense: it is not really a modifier of other layouts, it is really a whole layout per itself (not dependent on main layout at all).
> About splitting: home_row, left_hand and right_hand conflict. The numpad would > doesn't conflict with others, however, so it may make sense to include it in > all others. What about making numpad hidden and including it in 3 others? > I thought using a layout was the finest way. And to me it makes sense: it is > not really a modifier of other layouts, it is really a whole layout per itself > (not dependent on main layout at all). OK, I see. No problem. But it is actually related to the question regarding the country. So far xkeyboard-config layouts are built on per-country basis (except for 2 or 3 very special cases). Which country would be the best place for your layout/variants? US?
Created attachment 10429 [details] version with keypad hidden and included in others Here is a version with numpad hidden and included. About per-country... I'd say no country is the best place: the layout of raw braille dots themselves doesn't depend on the country, only on the physical geometry of the keyboard.
> Created an attachment (id=10429) [details] > version with keypad hidden and included in others Good! > About per-country... I'd say no country is the best place: the layout of raw > braille dots themselves doesn't depend on the country, only on the physical > geometry of the keyboard. Well, I would agree with "no country" approach - but how are these symbols used by people in the countries with non-latin alphabets? Or in Europe, where "extended Latin" is necessary? Please do not get me wrong, I just want to get the whole picture.
The Input Method will handle all that, it just needs raw braille dot patterns as input.
OK. So, the file would be put as symbols/braille. The default variant would be "home_row" (objections?). Also, I need nice user visible group descriptions (see other symbols/* files for example). > The Input Method will handle all that, it just needs raw braille dot patterns > as input. OK
Created attachment 10430 [details] with group description Here are group descriptions. Setting home_row as default variant should be fine.
Great! I'll commit it then
I have committed the stuff to CVS. Could you please check?
setxkbmap -layout fr,braille -variant latin9,home_row works fine. However, setxkbmap -layout fr,braille -variant latin9, doesn't. Is that expected? (I thought it should select home_row by default)
What kind of error do you get? Try setxkbmap ... -print | xkbcomp - :0 -w10 It could give more info on what's wrong. (In reply to comment #16) > setxkbmap -layout fr,braille -variant latin9,home_row works fine. However, > setxkbmap -layout fr,braille -variant latin9, doesn't. Is that expected? (I > thought it should select home_row by default) >
Oops, sorry, I meant: it doesn't fail, but no braille layout is applied on top of the fr layout.
Anyway, first look at the result of setxkbmap ... -print, then, as I said, feed it into xkbcomp. May be, "... | xkbcomp - -xkb out.xkb" would give you something interesting in out.xkb
Created attachment 10448 [details] xkb output This is the output. Not Group2 for qsdf & co. But I noticed the keypa has it. I tried putting back the keypad xkb_symbols section at the end of the "braille" file, and now home_row is correctly taken as default. It looks like xkb uses the first xkb_symbols section as default, regardless of the "default" qualifier.
It seems you're right about ignoring the default attribute. Should be ok in CVS now. Please check
Works fine now, thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.