On Wednesday 20 August 2003 7:18, Danilo Segan wrote: > ATM, the best GUI for this (advanced XKB control and management on the > user side) seems to be GSwitchIt: I believe you can find it at > http://gswitchit.sf.net/ > > (though, it requires at least some parts of a working Gnome 2 > environment)
KDE has a decent one built-in as well. Thought it requires KDE. :) > > I like the idea. While working on my proposal, I thought that a main > > keymap per script was the way to go. Have a latin, cyrillic, greek, > > gujarati base, and change from there (qwerty, azerty, etc.). > > At least cyrillic keyboards differ too much for this to work -- eg. > there are many "phonetic" keyboards (which are similar with english > ones based on the "sound") and there are completely different ones (a > standard Russian I believe to be an example of this). Well, one thing I do know is that I don't know very much about the different keyboards. :) I have access to three different kinds, but they're all Latin. Another reason to take these changes incrementally. > > > The idea is then to combine keyboard type (Apple, Sun, MS, ...) and > > > language mapping; something like "ng/keyboard(apple)+ng/sv(svorak)" > > > for a Swedish Dvorak mapping on an Apple keyboard. > > > > I really like the idea. However, I don't think we can move to fast. > > I'd prefer to do incremental changes towards something like this. > > Isn't a "keycodes" directory the right place for "hardware" stuff? This > should already be the case, unless I'm missing something. Not really. The keycodes just maps the low-level scan code to an X keycode. What the X keycode should do is up to the symbols. (Say, an Apple keyboard only has one alt key, so mapping Mode_switch to Alt_R doesn't work. So map Mode_switch to another key.) > > > And no, keymappings are not for countries, they are for languages, > > > though there may be some country variation, so names like en-US > > > (which is a RFC 3066 language tag) are quite appropriate. > > > > People have been thinking of these mappings as per country, and in > > some cases it makes more sense than mapping per language. Here in > > Switzerland, the keyboard is different than the keyboard in Germany, > > France, and Italy, and the people use it to type German, French, and > > English. Adding a different keymap to de, fr, and it in order to make > > the same keymap doen't make much sense (though it should just be an > > include "de(ch)"). > > And again, there we see why the approach of having *both* is a good > idea, with not too much work to do ;-) Agreed. > > Also, with the two-letter domain-names, people think that fr is > > France, not French, then add the flag of France to the keymaps > > (because flags look good in the GUI). The distinction between > > languages and countries can be very political. > > That's a GUI design issue, not a keymap design issue -- exactly that > was recently discussed in relevance to GSwitchIt, and there were many > comments on that side -- because of that, the "default" setting for > GSwitchIt has changed from displaying flags, to *language* labels (I > believe they're read from the Name[Group] stuff, though I'm not sure). > > All of this was done on Gnome HIG (Human Interface Guidelines) lists, > where there are many experts in GUI design -- so, your premise is > incorrect (about the tendency to use flags for the keymaps :-). Actually, here's a screenshot from the gswitchit page that shows that they did in fact use flags for keymaps: http://gswitchit.sourceforge.net/gsw.applet.png So, I stand behind by premise that developers tend to use flags for keymaps. Perhaps with a group to control these tendencies (like the HIG did for gswitchit) these tendencies can be changed. That's also why I want to be specific about what these 2-letter codes represent in Xkb. Frank _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
