> It's indeed the correct place.
Thank you! :)
> > Second, is this approach "the right one"? -->
> > setxkbmap -rules xfree86 -model pc104 -layout "us,dev" \
> > -option "grp:shift_toggle" -option "lv3:switch" -variant ",extra"
> This is where things are moving to; if I'm not mistaken, most
> keymaps have been modified in the CVS to behave like this.
It does feel "cleaner" not having the shift keys specified in the symbol
map. :)
> > partial default alphanumeric_keys
> > xkb_symbols "basic" {
> > include "pc/dev(bare)"
> > };
>
> Err, why are you using separate definitions of "basic" and "bare" that
> are exactly the same? The logical thing to do here is to move all the
> definitions that are currently in "bare" to "basic", and simply delete
> "bare". "extra" can than include "basic".
>
> The only keymap that has such a separation is the greek one (I should
> know, I maintain it), and there's a special reason for it (it gives it
> the ability to follow other keymaps for non-letter keys). I suspect you
> saw it from there...
Here, this was an artifact of when I was exploring the shift level 3 keys.
If I keep the map strictly INSCRIPT/Devanagari, I'll definitely move
bare's contents to basic. :)
Right now I'm trying to figure out exactly what similarities (if any) the
different INSCRIPT layouts have for other Indian scripts besides
Devanagari. I'm wondering if it's possible for me to rename this map to
"inscript", and then have users specify their script with inscript(dev) or
inscript(tml). If its possible for me to do such a thing, what do you
think would be "best"? Having one INSCRIPT keymap for several
(phonetically related) scripts? Or just make each script a separate map?
[ again, I'm still researching exactly how related are these different
scripts supported by INSCRIPT ]
> > partial alphanumeric_keys
> > xkb_symbols "extra" {
> > include "pc/dev(bare)"
> >
> > key.type[Group1]="FOUR_LEVEL";
> >
> > // I want to be able to type \ / ? | for file names and piping...
> > key <AB10> { [ U092f, U095f, slash, question ] };
> > key <BKSL> { [ U0949, U0911, backslash, bar ] };
> >
> > // I also wanted to be able to type nifty circle glyph such as when
> > // demo'ing the modifiers, vowels, combining characters, etc...
> > // space, circle, ZWNJ, ZWJ:
> > key <SPCE> { [ space, U25cc, U200c, U200d ] };
> > };
>
> Again, is there any reason to separate these from the rest? My guess
> is that the definitions below are the "official" ones, and these ones
> are extensions of yours. But if others might find them useful, it
> might be worth merging them with the rest. And if not, it might not be
> worth including them in the submitted file at all. ;^) But of course,
> the choice is yours.
Yes, I did try separating the symbols into the "mostly-standard" and the
"I wanted these extra keys-standard". :) I vaguely recall reading a
small advisory in one of the XKB howto's, to keep submitted keymaps as
close to some standard as possible with minimal "personalizations".
hmm... how strictly should I adhere to this recommendation?
> > //AE03-AE08 really need to return a macro of keys defined by INSCRIPT
> > //in place of the NoSymbol's that are here for now.
> > // How do I get XKB to let 1 key translate to pressing 2-3 other keys?
> I don't think you can do that, unfortunately.
Yeah, I saw some other posts a few months ago across the X mailing lists
(I forget which) talking about keyboard macros --- seemed like general
opinion that macros are best handled at a higher level than inside X.
It's too bad that INSCRIPT declared a few convenience keys in it: many of
the characters (such as vowels and "r") are actually "modifiers" of sorts
for neighboring glyphs. ( rough example: instead of typing "cut", you'd
type c <vowel u> t, but it gets displayed as Ct, where C is some cute
combination of c+u ) Well, these "convenience/combo keys" replace 2-3
other key presses for frequently used letter combinations. It's too bad
the Microsoft & Java people can support these "combo-keys" in their
keymaps and not X..... :) I wouldn't mind helping out with making such a
feature addition to the source... if possible.
> > //I'm debating between which of the two following lines is correct:
> > // key <AE11> { [ U0903, U0903, minus, underscore ] };
> > key <AE11> { [ NoSymbol, U0903, minus, underscore ] };
>
> Probably the first one, unless you *really* want this key to do
> nothing at all when pressed by itself.
Yeah, I prefer the first line myself, though, I'm not sure if it is
strictly standard. (I wish I new the reason for leaving that position
empty.)
Thank you for the advice / feedback! :)
- David
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
