Quoting Anton Zinoviev (an...@lml.bas.bg): > > I have not seen any single "Georgian" keyboard in my entire computing > > life in France. > > Actually fr(geo) is not for Georgian keyboards. It is for typing > Georgian on a French keyboard.
My point.... There is no such physical keyboard. Apparently, from what you mention, various keyboard layouts are added, more or less randomly, because someone once worked on one. This is about the same crazyness we had with console layouts in the good old days, where everybody was inventing his|her own "layout" (fr-latin1, fr-latin9, fr-latin0....). If upstream xkb has such policy, I'm afraid it is entirely entering a neverending nightmare of piling up "layouts" and "variants" for each and every crazy ideas in the world. Anyway, this is getting off-topic. I'm not in position to change XKB policy, nor do I want it. Here, I'm interested in the consequences we have in D-I.... > > > layouts, but with time this filtering will become so distant from what > > > the upstream is providing us that it will become a nightmare to support > > > it. > > > > I see absolutely no reason for this. I'm proposing to just make that > > choice each time a language is added to D-I. We're doing this for > > years (actually since D-I exists). > > Console-data was maintained by you, i.e. by a member of d-i team. My > concern is that Xkeyboard-config changes more rapidly than console-data. As said, the point is not changing xkeyboard-config. The point is in still keeping the idea of "the same keyboard management system in D-I and, later, at the system's console, than the one in X"....while keeping this manageable and scalable for D-I. > BTW, it seems to me that there is no other file in XKB with such a > diversity of variants as the French file. :) I don't know whether all The German one is also quite interesting....which is not a surprise: we find there the very same mess we have in console keymaps, inherited from the days where people where thinking it is good to "invent" their own keyboard layout and publish it everywhere because it was working on their own kitchen sink...:-) BTW, this is what I personnally think about those crazy Dvorak keymaps but don't tell this to the Dvorak and Bépo keymaps addicts..:-) > these variants are realy used or not, but if they are not, one method to > deal with this mess is to mark some of the variants in the file with the > keyword "hidden". In this way these variants will be still supported > but the configuration programs will not present them to the users. If > there is agreement between the French users, the upstream can be > convinced to make the changes. I'm not sure that belongs to upstream, again. We should refocus on our point, here: D-I. I'm not interested in changing things upstream, or even changing the way you deal with them in the standard console-setup package. You're certainly handling things the right way. The point is the udeb. I'm currently convinced and still need to be unconvinced that we have to shrink the number of proposed layouts to a list with only 1 or 2 layouts per language, plus some country-specific cases (e.g. the Brazilian layouts). That means having a specific way to ask for layouts *in a single question* mor eor less combining the layout/variant (and maybe model) questions. This only in D-I. Probably with a specific console-setup-udeb.postinst script instead of using the big cs-.postinst and c-s.config scripts. I see this as the only way to preserve one key feature of D-I: keeping things simple for users and minimizing the number of asked questions. And, also, preserve the rationale where "size matters".
signature.asc
Description: Digital signature
