Nicolas Mailhot wrote:
The problem is - most users wouldn't care less if there was a single
clean layout per language or group of languages (we wouldn't
Yes, but that requires some standardisation effort.
be in this mess for example if there was a single latin layout and
countries hadn't
Le mar 26/08/2003 à 16:09, Kent Karlsson a écrit :
Nicolas Mailhot wrote:
The problem is - most users wouldn't care less if there was a single
clean layout per language or group of languages (we wouldn't
Yes, but that requires some standardisation effort.
be in this mess for example
Le sam 16/08/2003 à 19:34, Frank Murphy a écrit :
On Thursday 14 August 2003 11:02, Danilo Segan wrote:
fr file governs keymaps for the French language, and it's sane (I
already mentioned that there are other criteria, like population -- the
criterium of language origin is just a sample
Le jeu 14/08/2003 à 17:35, Frank Murphy a écrit :
Sorry, I meant shift levels. my proposed us-ascii would have just
key AE01 { [ 1,exclam ] };
not
key AE01 { [ 1, exclam, onesuperior, exclamdown ] };
I'd go for:
key AE01 { [
On Friday 22 August 2003 10:25, Ivan Pascal wrote:
Hi,
Frank Murphy wrote:
So what's the difference between alt+c on Mac OS and Multi_key+, on X11?
Is it just the display of the greyed-out character? I had thought that a
dead key was a real key on the keyboard (that had the accent
David Dawes wrote:
remove the latin1 key symbols from the macintosh/us keymap.
(Supposedly, it's
got #5386, but I don't know in what system!)
Here is the text associated with that patch:
There is a lot of stuff in this file that doesn't make sense for a
symbols file that calls
Danilo Segan wrote:
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 --
Frank Murphy wrote:
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.
And the text next to the flags
On Thursday 21 August 2003 3:38, Kent Karlsson wrote:
Frank Murphy wrote:
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
On Thursday 21 August 2003 3:37, Kent Karlsson wrote:
Danilo Segan wrote:
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
That gives at least two *basic* layouts for Cyrillic,
probably less than
a handfull *basic* layouts for Cyrillic (there being two
[that I know
of] for Latin). The reast would be per language
modifications of that.
There are more for Latin, depending on what you consider
*basic*:
Frank Murphy wrote:
Absolutely on Mac OS. In the US (where therre are no deadkeys),
Yes there are (see below).
in order to type on Mac OS (9 X), press alt/option+c,
then press c again. alt+u is for umlaut, etc.
alt/option+c is a dead key (the MacOS X UI shows a yellow background
and an
On Thursday 21 August 2003 4:55, Kent Karlsson wrote:
Frank Murphy wrote:
Absolutely on Mac OS. In the US (where therre are no deadkeys),
Yes there are (see below).
in order to type on Mac OS (9 X), press alt/option+c,
then press c again. alt+u is for umlaut, etc.
alt/option+c is a
Sorry, I meant shift levels. my proposed us-ascii would have just
key AE01 { [ 1,exclam ] };
not
key AE01 { [ 1, exclam, onesuperior, exclamdown ] };
Sorry for misusing the terminology.
But basicaly, this could be done simply without breaking
On Tuesday 19 August 2003 5:04, David Dawes wrote:
Or maybe all of the xkb config files can go to a new location outside
of xc/programs/xkbcomp. Once there is a good proposal for a more
consistent and logical structure for all of these files, they can be
moved. That way we don't need to be
On Thursday 14 August 2003 11:02, Danilo Segan wrote:
fr file governs keymaps for the French language, and it's sane (I
already mentioned that there are other criteria, like population -- the
criterium of language origin is just a sample one, for the sake of
discussion) to have a default
(I was just arguing against *country-only* based keymap names. That's
the whole point. I don't mind country based keymaps, if there are also
language based keymaps)
As soon as you mentioned this, I agreed. What I'm suggesting now is 2-letter
national code keymaps and 3-letter linguistic code
On Fri, 15 Aug 2003, Frank Murphy wrote:
If systems are single-user, which defeats the purpose of X network
transparency. In multi-user environments, you cannot expect every user
to use the same language in every occasion.
I imagine that most X deployments are single-user. Plus I imagine
Danilo Segan [EMAIL PROTECTED] writes:
On Thu, 14 Aug 2003, Danilo Segan wrote:
For the sake of difference, I would recommend the following:
- National keymaps should use ISO 3166 code in all UPPERCASE (eg.
US)
- Linguistic keymaps should use ISO 639 code in all lowercase (eg.
, 14. 2003. 04:32:57 CEST Frank Murphy :
Sorry, I meant shift levels. my proposed us-ascii would have just
key AE01 { [ 1,exclam ] };
not
key AE01 { [ 1, exclam, onesuperior, exclamdown ] };
I'd go for:
key AE01 { [ 1, exclam,
Dr Andrew C Aitchison wrote:
Is there a difference between CA(fr) and fr(CA)*
Does the user care about it ? Should we make them mean the same thing ?
*FR(ca) would be different, although possibly unimportant or meaningless.
I think there is a minor difference.
In such name the first word
, 14. 2003. 13:12:05 Dr Andrew C Aitchison :
On Thu, 14 Aug 2003, Danilo Segan wrote:
For the sake of difference, I would recommend the following:
- National keymaps should use ISO 3166 code in all UPPERCASE (eg.
US)
- Linguistic keymaps should use ISO 639 code in all lowercase (eg.
On Thu, 14 Aug 2003, Danilo Segan wrote:
For the sake of difference, I would recommend the following:
- National keymaps should use ISO 3166 code in all UPPERCASE (eg. US)
- Linguistic keymaps should use ISO 639 code in all lowercase (eg. en)
Is this going to cause us to run into CVS problem
, 13. 2003. 18:58:40 CEST Frank Murphy :
The only xkb_symbols us that I see are in digital/us and
xfree68/ataritt.
But the map would be the same as the xkb_symbols basic in pc/us,
basically, the same as latin(basic) only not including the group 2 or
3 symbols (exclamdown, etc.). However, it
, 14. 2003. 17:35:10 CEST Frank Murphy :
I'd go for:
key AE01 { [ 1, exclam, any, any ] };
(I'm not sure if your idea would work like this -- if it would,
then this is unneccessary burden).
It's already done with only two levels in the pc/us keymap. I don't
see a reason to
Sorry, I meant shift levels. my proposed us-ascii would have just
key AE01 { [ 1,exclam ] };
not
key AE01 { [ 1, exclam, onesuperior, exclamdown ] };
I'd go for:
key AE01 { [ 1, exclam, any, any ] };
(I'm not sure if your
The only xkb_symbols us that I see are in digital/us and
xfree68/ataritt.
But the map would be the same as the xkb_symbols basic in pc/us,
basically, the same as latin(basic) only not including the group 2 or
3 symbols (exclamdown, etc.). However, it would be in the latin file
and
No, I didn't mean to imply that FR was choosen as a default for fr
because of textual similarity, but rather, because France, with ISO
3166 code of FR, is the originator of French language fr (perhaps
this is not a good enough reasoning, and your reasoning based on
population might be more
28 matches
Mail list logo
