|
|
Hi Thanos,
Yesterday at 1:42, Thanos Kyritsis wrote:
> The problem is about consistency and backwards compatibility. This is
> the 3rd time the greek layout is changing. This bug only raised the
> issue for one more time.
Exactly: for consistency sake, xkeyboard-config uses only country codes.
For backwards compatibility, it introduces compat rule for "el".
> We actually do not have greek keyboards. The keyboards being sold in
> Greece are basically American (us) layout keyboards with a greek
> language "support layer" on top of them.
> This means that ~50% of the keyboards used in Greece have no difference
> compared to the American layout keyboards and for the other ~50% some
> buttons have an extra smaller sticker below them representing the greek
> letter. For example, letter A is common in English and Greek. But the
> button for letter D has a 2nd smaller sticker on it
> representing the greek delta letter.
All keyboards are mostly the same and they differ only in the
"stickers" on top of them (i.e. they send the same keycodes).
> So, based on this reality, and taking *ONLY* for consideration and *NOT*
> for example what Microsoft Windows do (they do the 'el' thing), we came
> to the conclusion that the correct way was to define our layout by
> using the ISO *language* (639) code and not the *country* (ISO-3166)
> code.
This doesn't matter. Layout is probably regulated by Greek standards
body (Hellenic Organization for Standardization? perhaps a
chapter/member of ISO?), and by extension, it's the layout of the
country of Greece. IMHO, at least.
> This fact is also double confirmed by the following fact:
>
> For example someone has bought a laptop from UK and the keyboard follows
> the GB layout and wants to write in Greek. He will not change his
> laptop's keyboard layout to GR, he will simply add a layer *on top* of
> his current GB layout in order to support Greek. Everything else which
> is common to both languages (for example buttons a, e, i, T, and so on)
> still has to follow the originating keyboard layout (which is GB) and
> not the originating GR layout of keyboards sold in Greece which is
> basically US.
As I said, keyboards differ only in what stickers manufacturers put on
them (and a couple of keys). Most layouts easily fit on UK/US
keyboards.
> And now, the consequences. I can see that XKeyboardConfig's developer is
> Russian, and I believe you can understand how many years of true pain
> and efforts and searching and digging and fights we have been through
> in order to at last obtain a true stabilized and rock steady Greek
> Localization/Internationalization support in Linux, BSD and other
> unix-derivatives or unix-like Operating Systems that rely on X.
The file name of Greek layout should be a non-issue: it's an
implementation detail, and choosing a single scheme is there to help
maintainers. Users (both people and programs) are expected to offer
their choices using base.xml or appropriate library.
> Many years of building howtos, guides, instructions, submitting patches
> to Linux distros and so on ... You are aware of all these actions made
> by volunteers, I'm sure.
>
> It is of great importance that seemingly small things like the 'gr' or
> 'el' naming of such a basic component as the keyboard layout are to
> remain somewhat stable and not change their name every two years
> because this has the effect of chain reaction. All next Linux distros
> that will ship with X.org 6.9.0/7.0 will have broken greek support,
> applications and applets for uses like displaying a flag up to changing
> the keyboard layout will break, guides will break, howtos will break
> (again).
"setxkbmap el" should still work, afaik if compat rules are enabled.
However, it's pretty unlikely someone will update their X.org to the
latest revision and not update other software (which is more likely to
support xkeyboard-config and new proposed ways for accessing layouts).
The problem happens for guys using bare X.org with
xkeyboard-config-originating base.xml or xorg.xml.
> I agree that the end user doesn't have to care about these low level
> things. I also state that I as a power user can easily 'hack' the guts
> out of a X.org cvs bundle and bring it under my own likes. But the
> point is to finally stabilize a naming for the greek layout and not
> having it change every 10 X releases.
The renaming that took place in xkeyboard-config touched much more
than just Greek. The same happened to Serbian (now "cs"), and many
other layouts.
> Sorry for this huge post, but I hope to have shaded with light every
> aspect of this. I would like to ask from you to reconsider on the
> naming of the kb layout, and take a final decision, the greek i18n
> community can help as much as it can and in every way, submit patches
> for fixing the X.org bug, resync X.org with XkeyboardConfig under an
> emergency-like situation and try to reduce the consequences from the
> 'gap' that this bug will leave behind it.
Basically, the problem is that main X.org tree hasn't seen significant
updates for ages now, so it's out of sync with xkeyboard-config.
For reference, it works correctly in Ubuntu (as Simos reported in the
bug) since Ubuntu is using xkeyboard-config.
Cheers,
Danilo
|
|