Zompist Bboard Again

Posted: **Sun Nov 24, 2019 2:32 pm**

Ser wrote: ↑Sat Nov 23, 2019 6:45 pm I don't quite understand what you're going on about. Cuneiform and Egyptian are logographies, wouldn't the obvious way to go be full-blown input method editors, i.e. what Chinese and Japanese do? Type "inanna", type a number to chose from a small pop-up list, and get 𒈹.

Egyptian works as an abjad script with an inordinate number of biliteral and multiliteral signs, plus a batch of logographic determinatives. Many determinatives double as phonetic signs. I've coded up the signs using what I could find of the MdeC (Manuel de Codage) codes, and with Gardiner codes available for everything. It's quicker to type nfrw and get 𓄤𓅱 than to be presented with a choice for nfr including 𓄤𓆑𓂋. (Unicode didn't have the layout characters when I encoded the keyboard.) I use hyphens to enforce character boundaries, but M17n works very quickly in this case because 'nfr' is not the prefix of any other character code. So, typing 'nfr-w-' also yields 𓄤𓅱.

I would take cuneiform systems as semisyllabaries with add-ons. Thus I would just type mush3 to get the logogram for "Inanna", and an-mush3 to prefix it with the determinative DINGIR to write it in the normal fashion. I'd also allow dingir-mush3 and probably dingir-inanna.

Now, one might consider adding prompts to a shared keyboard, but if I couldn't remember which 'mush' to use for Inanna, I'd just grep a plain text sign list - with a little work, the keyboard definition file would serve the function. Did you have in mind typing in an Akkadian word in ASCII and getting a list of possible spellings?

The Windows interface MSKLC makes DLLs for can't handle these scripts - dead key sequences yield one BMP character (these are SMP characters) and there aren't enough Bucky bits.

Posted: **Sun Nov 24, 2019 2:53 pm**

A portion of my M17n keyboard definition file for Egyptian hieroglyphs reads:

Code: Select all

  ("M17"  0x131CB) ("M17-"  0x131CB) ; 𓇋 EGYPTIAN HIEROGLYPH M017
  ("i"    0x131CB) ("i-"    0x131CB)
  ("M17A"    0x131CC) ("M17A-"    0x131CC) ; 𓇌 EGYPTIAN HIEROGLYPH M017A
  ("Y"       0x131CC) ("Y-"       0x131CC)
  ("i*i"     0x131CC) ("i*i-"     0x131CC)
  ("M17*M17" 0x131CC) ("M17*M17-" 0x131CC)
  ("M18"  0x131CD) ("M18-"  0x131CD) ; 𓇍 EGYPTIAN HIEROGLYPH M018
  ("ii"   0x131CD) ("ii-"   0x131CD)

I also took some compound codes for characters from Unicode Technical Note (UTN) #32.

Posted: **Sun Nov 24, 2019 4:40 pm**

Richard W wrote: ↑Sun Nov 24, 2019 12:00 pm
bradrn wrote: ↑Sat Nov 23, 2019 9:11 pm Does anyone have any idea how to get dead keys in a Linux keyboard layout? As mentioned above, I’ve figured out the basics, but there doesn’t seem to be any documentation on how to make dead keys. All I know so far is that one can use dead_acute, dead_grave etc., but I need a little bit more control if I want to port Conkey over.
First, let me point out that you are currently talking about X, rather than Linux. There are other schemes in Linux, with frameworks like scim (abandoned?), ibus and fcitx, and interfacing keyboard definitions defined by, amongst others, KMfL and M17n, as well as input methods that include their own interfacing with these frameworks. KMfL relies on the characters formed by a US keyboard, which is rather limiting.

X has explicit dead key characters, but formally it is the responsibility of the application to combine dead kay and following key to make the required character. The combination that should be supported is language-dependent, but fortunately, many applications support them all regardless.

There is also a 'compose' mechanism available for X applications, which seems to require the use of a 'compose' key. I haven't investigated this one, and I don't know how widespread support is amongst applications.

I should have expected something like this. Why can’t anything in Linux be simple‽ (And yes, I know that Windows can be quite a bit more complicated in areas, but at least there are resources for Windows…)

Anyway, given that I want to make Conkey available as widely as possible, which of the above (X, scim, ibus, fcitx, KMfL, M17n, compose key) do you think I should target?

Posted: **Sun Nov 24, 2019 6:36 pm**

Richard W wrote: ↑Sun Nov 24, 2019 12:00 pmFirst, let me point out that you are currently talking about X, rather than Linux. There are other schemes in Linux, with frameworks like scim (abandoned?), ibus and fcitx, and interfacing keyboard definitions defined by, amongst others, KMfL and M17n, as well as input methods that include their own interfacing with these frameworks. KMfL relies on the characters formed by a US keyboard, which is rather limiting.

X has explicit dead key characters, but formally it is the responsibility of the application to combine dead kay and following key to make the required character. The combination that should be supported is language-dependent, but fortunately, many applications support them all regardless.

Okay, I just spent an hour and a half reading about how keyboard input works on Linux. And huh. All this time I had been (wrongly) thinking that Fcitx and IBus were keyboard signal interpreters, which then passed their interpretation onto X or Wayland, which then passed the interpretation onto the application as input... But yeah, it seems Fcitx and IBus run as user apps and directly send input signals into programs, so it's the programs that handle dead keys. I guess it usually works because so many programs simply use appropriate GTK or Qt library inputs, or if they use something homemade, they're friendly to Fcitx and IBus (like LibreOffice and the Java GUI libraries).

Although I'm not quite sure what to think, because I'd find it incredible that LibreOffice and Java really have their own implementation of dead key input... Also, I'm on Ubuntu 19, which runs on the X window system and the IBus input method by default, and it is also the case that if I edit the "us" file in /usr/share/X11/xkb/symbols/ (ostensibly an X configuration directory, maybe for old XIM?), my IBus layout for the US keyboard layout does change. But maybe IBus just loads the files of this directory, besides the ones in /usr/share/ibus/.

It doesn't appear that IBus dead key behaviour is defined anywhere in /usr/share/ibus/ or /usr/share/X11/ though, so maybe it's hardcoded into the program itself. Just as you found it was the case with Fcitx...

Finally I'd like to mention that IBus works great with AltGr dead keys out of the box. If I select the "English (US, intl., with dead keys)" layout, I get a bunch of AltGr dead keys like AltGr+. (that is AltGr plus dot) for a dot above letters (ȧċėȯ), and even Shift combinations like AltGr+Shift+3 for macrons (āēōǖ). The problem is that to alter the behaviour of dead_macron, you'd probably need to patch IBus itself somewhere...

Richard W wrote: ↑Sun Nov 24, 2019 2:32 pmEgyptian works as an abjad script with an inordinate number of biliteral and multiliteral signs, plus a batch of logographic determinatives. Many determinatives double as phonetic signs. I've coded up the signs using what I could find of the MdeC (Manuel de Codage) codes, and with Gardiner codes available for everything. It's quicker to type nfrw and get 𓄤𓅱 than to be presented with a choice for nfr including 𓄤𓆑𓂋. (Unicode didn't have the layout characters when I encoded the keyboard.) I use hyphens to enforce character boundaries, but M17n works very quickly in this case because 'nfr' is not the prefix of any other character code. So, typing 'nfr-w-' also yields 𓄤𓅱.

Well, Egyptian writing varied like that, so perhaps it would be desirable to type "nfr" and get a popup prompt with all of 𓄤, 𓄤𓂋, 𓄤𓆑𓂋. Also, aren't there logograms that in terms of their phonetic value would share the same consonant sequences?

I would take cuneiform systems as semisyllabaries with add-ons. Thus I would just type mush3 to get the logogram for "Inanna", and an-mush3 to prefix it with the determinative DINGIR to write it in the normal fashion. I'd also allow dingir-mush3 and probably dingir-inanna.

Now, one might consider adding prompts to a shared keyboard, but if I couldn't remember which 'mush' to use for Inanna, I'd just grep a plain text sign list - with a little work, the keyboard definition file would serve the function. Did you have in mind typing in an Akkadian word in ASCII and getting a list of possible spellings?

You know, it's funny because now you're making me wonder what Chinese and Japanese speakers do when they similarly forget something like that. Surely at some point users of Traditional Chinese must doubt which fù logogram they should use in a given compound out of 復 'again' and 複 'again, complex', since both characters stand for similar meanings but aren't always interchangeable, e.g. fùxí 'to review' can be 復習 or 複習, but fùhégōng 'composite bow' can only be 複合弓 because the first fù stands for "complex"). I've never seen a Mandarin speaker checking which logogram is needed in cases like this, and I wonder what websites or apps are popular, etc.

bradrn wrote: ↑Sun Nov 24, 2019 4:40 pmI should have expected something like this. Why can’t anything in Linux be simple‽ (And yes, I know that Windows can be quite a bit more complicated in areas, but at least there are resources for Windows…)

Nah, that's not necessarily the case. It's just a matter of there not being many people wanting to do custom layouts. I can only imagine what it'd take to find out how to do a custom input method for Egyptian or some logographic conscript for Windows. I once saw someone's simple, homemade Windows input method for Cantonese so that it'd work with Jyutping, so I believe doing such a thing for Egyptian or a logographic conscript should be possible, but...

Anyway, given that I want to make Conkey available as widely as possible, which of the above (X, scim, ibus, fcitx, KMfL, M17n, compose key) do you think I should target?

In terms of frameworks, since you use plenty of AltGr dead keys, I imagine IBus will turn out to be friendlier than Fcitx (or the now-abandoned SCIM, or the old and clunky X(IM)). I'm assuming (likely safely) that Richard is correct when talking about Fcitx's buggy behaviour with regard to AltGr dead keys.

In terms of engines, I have no idea which of KMFL or M17N will turn out to be friendliest. The Compose engine is funny in this case because it already has a large number of dead key combinations (that's its whole shtick). I see a bunch of Compose files organized by Linux locale (like "en_US.UTF-8") in /usr/share/X11/locale/, and the files do include definitions of dead key behaviour. That could be the easiest thing to do, but then there's the problem that the people who use Compose likely won't want their Compose behaviour altered. XD

Posted: **Sun Nov 24, 2019 7:32 pm**

Ser wrote: ↑Sun Nov 24, 2019 6:36 pm
Anyway, given that I want to make Conkey available as widely as possible, which of the above (X, scim, ibus, fcitx, KMfL, M17n, compose key) do you think I should target?
In terms of frameworks, since you use plenty of AltGr dead keys, I imagine IBus will turn out to be friendlier than Fcitx (or the now-abandoned SCIM, or the old and clunky X(IM)).

I’ll try to use iBus then. Let’s hope it works!

Posted: **Mon Nov 25, 2019 11:46 am**

Ser wrote: ↑Sun Nov 24, 2019 6:36 pm Okay, I just spent an hour and a half reading about how keyboard input works on Linux. And huh. All this time I had been (wrongly) thinking that Fcitx and IBus were keyboard signal interpreters, which then passed their interpretation onto X or Wayland, which then passed the interpretation onto the application as input... But yeah, it seems Fcitx and IBus run as user apps and directly send input signals into programs, so it's the programs that handle dead keys. I guess it usually works because so many programs simply use appropriate GTK or Qt library inputs, or if they use something homemade, they're friendly to Fcitx and IBus (like LibreOffice and the Java GUI libraries).

You're grossly oversimplifying. The one system I have studied in annoyed detail is IBus plus KMfL (not to be confused with modern Keyman for Linux). When a program is running via X, the keystroke events come into the program, which may pass them to its X input method. The XIM backed can be one of several, including IBus and fcitx. X has identified the relevant 'symbol on the key', i.e. a character (Unicode or dead key), and passes the states of the modifier keys to the engine, in this case IBus. IBus then passes the key on to KMfL, which interprets it according to the selected KMfL keyboard. Now, KMfL can either access the applications backing store directly for the character buffer, or can pass strings (including rubout characters) to the application through the XIM mechanism. Race conditions are not unknown - I've had grief when using a Windows 7 laptop as an X-terminal to run an application on a Linux machine. Finally, IBus (and fcitx) can just serve up the X11 keyboards, which act as they should. This is when modifiers such as AltGr work without problem - except that each symbol on a key can only be a single character. (I have keyboards that have all the characters of an alphabet, not just those with Unicode codepoints.)

KMfL used to use the current X11 keyboard for character interpretation, but the general behaviour nowadays is for the base X11 keyboard to be set to the US keyboard.

Ser wrote: ↑Sun Nov 24, 2019 6:36 pm But maybe IBus just loads the files of this directory, besides the ones in /usr/share/ibus/.

Exactly.

Ser wrote: ↑Sun Nov 24, 2019 6:36 pm Well, Egyptian writing varied like that, so perhaps it would be desirable to type "nfr" and get a popup prompt with all of 𓄤, 𓄤𓂋, 𓄤𓆑𓂋. Also, aren't there logograms that in terms of their phonetic value would share the same consonant sequences?

I think I would find having to make the choice tedious. Now, there are some biliterals that have the same transliteration , e.g. the pair ASCIIfied to 'ab'. I can type one with 'ab', but for the other I have to use its Gardiner code. (Gardiner codes are available for everything.) What's certain is that setting that up is more complicated.

Ser wrote: ↑Sun Nov 24, 2019 6:36 pm
I would take cuneiform systems as semisyllabaries with add-ons. Thus I would just type mush3 to get the logogram for "Inanna", and an-mush3 to prefix it with the determinative DINGIR to write it in the normal fashion. I'd also allow dingir-mush3 and probably dingir-inanna.

Now, one might consider adding prompts to a shared keyboard, but if I couldn't remember which 'mush' to use for Inanna, I'd just grep a plain text sign list - with a little work, the keyboard definition file would serve the function. Did you have in mind typing in an Akkadian word in ASCII and getting a list of possible spellings?
You know, it's funny because now you're making me wonder what Chinese and Japanese speakers do when they similarly forget something like that. Surely at some point users of Traditional Chinese must doubt which fù logogram they should use in a given compound out of 復 'again' and 複 'again, complex', since both characters stand for similar meanings but aren't always interchangeable, e.g. fùxí 'to review' can be 復習 or 複習, but fùhégōng 'composite bow' can only be 複合弓 because the first fù stands for "complex"). I've never seen a Mandarin speaker checking which logogram is needed in cases like this, and I wonder what websites or apps are popular, etc.

Would a grammar or spelling checker help?

bradrn wrote: ↑Sun Nov 24, 2019 4:40 pmI should have expected something like this. Why can’t anything in Linux be simple‽ (And yes, I know that Windows can be quite a bit more complicated in areas, but at least there are resources for Windows…)

Nah, that's not necessarily the case. It's just a matter of there not being many people wanting to do custom layouts. I can only imagine what it'd take to find out how to do a custom input method for Egyptian or some logographic conscript for Windows.

Ser wrote: ↑Sun Nov 24, 2019 6:36 pmI once saw someone's simple, homemade Windows input method for Cantonese so that it'd work with Jyutping, so I believe doing such a thing for Egyptian or a logographic conscript should be possible, but...

So far the best I've come up with is to to use Keyman for Windows, but I'm having trouble working out how to commit the text. So far I can only come up with an impermanence character before the input point. A lot depends on whether <SPACE, BACKSPACE> commits or not - I worry that that functionality may vanish.

Ser wrote: ↑Sun Nov 24, 2019 6:36 pm
Anyway, given that I want to make Conkey available as widely as possible, which of the above (X, scim, ibus, fcitx, KMfL, M17n, compose key) do you think I should target?
In terms of frameworks, since you use plenty of AltGr dead keys, I imagine IBus will turn out to be friendlier than Fcitx (or the now-abandoned SCIM, or the old and clunky X(IM)). I'm assuming (likely safely) that Richard is correct when talking about Fcitx's buggy behaviour with regard to AltGr dead keys.

AltGr *modifiers* for an X11 keyboard work fine with fcitx.

My recommendation would be to go for M17n and set up an alternative to AltGr. I use '!' as a deadkey. You will then have a choice of at least two engines - fctix and IBus - to run the keyboard definition. A bolder alternative would be to go for Keyman - the missionaries' support group (SIL) has made it free, though they do solicit donations. A Keyman implementation should work across operating systems - Windows, Linux and Mac at least. It supports dead keys if you really want them. I'm not sure about modifier support.

Posted: **Mon Nov 25, 2019 6:15 pm**

Richard W wrote: ↑Mon Nov 25, 2019 11:46 am
Ser wrote: ↑Sun Nov 24, 2019 6:36 pm
Anyway, given that I want to make Conkey available as widely as possible, which of the above (X, scim, ibus, fcitx, KMfL, M17n, compose key) do you think I should target?
In terms of frameworks, since you use plenty of AltGr dead keys, I imagine IBus will turn out to be friendlier than Fcitx (or the now-abandoned SCIM, or the old and clunky X(IM)). I'm assuming (likely safely) that Richard is correct when talking about Fcitx's buggy behaviour with regard to AltGr dead keys.
AltGr *modifiers* for an X11 keyboard work fine with fcitx.

My recommendation would be to go for M17n and set up an alternative to AltGr. I use '!' as a deadkey. You will then have a choice of at least two engines - fctix and IBus - to run the keyboard definition.

Do you think this will be enough to support the features of Conkey? (Everything is on AltGr, lots of dead keys with custom mappings)

A bolder alternative would be to go for Keyman - the missionaries' support group (SIL) has made it free, though they do solicit donations. A Keyman implementation should work across operating systems - Windows, Linux and Mac at least. It supports dead keys if you really want them. I'm not sure about modifier support.

I did — very briefly — use Keyman myself, but didn’t like it all that much. It certainly has enough features to rewrite Conkey, but if you’re willing to use Keyman then there are already other keyboards you can use which are at least as good as Conkey. (I liked EuroLatin and BU keyboard.)

Posted: **Mon Nov 25, 2019 8:30 pm**

bradrn wrote: ↑Mon Nov 25, 2019 6:15 pm
Richard W wrote: ↑Mon Nov 25, 2019 11:46 am My recommendation would be to go for M17n and set up an alternative to AltGr. I use '!' as a deadkey. You will then have a choice of at least two engines - fctix and IBus - to run the keyboard definition.
Do you think this will be enough to support the features of Conkey? (Everything is on AltGr, lots of dead keys with custom mappings)

Yes. Here's an example of an AltGr- as wanted alongside the '!' deadkey alternative. I wanted AltGR-2 to be the keystrokes to enter the character.

Code: Select all

((G-2) ?᪨) ("!2" ?᪨)          ; U+1AA8 TAI THAM SIGN KAAN

The documentation is at https://www.nongnu.org/m17n/. What you have above are two expansions of KEYSEQ.

Posted: **Mon Nov 25, 2019 8:37 pm**

Richard W wrote: ↑Mon Nov 25, 2019 8:30 pm
bradrn wrote: ↑Mon Nov 25, 2019 6:15 pm
Richard W wrote: ↑Mon Nov 25, 2019 11:46 am My recommendation would be to go for M17n and set up an alternative to AltGr. I use '!' as a deadkey. You will then have a choice of at least two engines - fctix and IBus - to run the keyboard definition.
Do you think this will be enough to support the features of Conkey? (Everything is on AltGr, lots of dead keys with custom mappings)
Yes. Here's an example of an AltGr- as wanted alongside the '!' deadkey alternative. I wanted AltGR-2 to be the keystrokes to enter the character.
Code: Select all
((G-2) ?᪨) ("!2" ?᪨)          ; U+1AA8 TAI THAM SIGN KAAN
The documentation is at https://www.nongnu.org/m17n/. What you have above are two expansions of KEYSEQ.

Thanks! I’m still a bit confused about m17n though: from the documentation, it looks more like a text manipulation library rather than a keyboard layout creation library. Could you explain how I can use it to make keyboards?

Posted: **Tue Nov 26, 2019 12:30 pm**

bradrn wrote: ↑Mon Nov 25, 2019 8:37 pm Thanks! I’m still a bit confused about m17n though: from the documentation, it looks more like a text manipulation library rather than a keyboard layout creation library. Could you explain how I can use it to make keyboards?

Monkey see, money do is the best way to get started. If you've got m17n-db set up, running it will tell you the name of the directory containing the system M17n data files. User data files go in the directory ~/.m17n.d. All the data files are text files. The keyboard layout definitions are the .mim files. They look like lisp (Lots of Irritating Silly Parentheses), but By default, what you type is what you get. Semicolons introduce end-of-line comments - but with the naughty habit of having directives within comments.

The file latn1-pre.mim gives you the sort of thing one typically does with dead keys - under the heading 'dead keys'. Now, this keyboard doesn't hide the dead key - if you press the key, you see something. but it gives you the dead key functionality. It also has the AltGr capability with 'AltGR/t yields thorn' implemented by the line "((G-t) ?þ)". This line is a production of 'RULE in the syntax definition.

So, you edit the file, put it in the correct directory, and induce the framework to use it. Oh, and you set up environment variables so all the processes know which framework you want to use. The method of inducing is a bit unstable - you may need to ask for your particular distribution, quoting version and desktop manager, e.g. Gnome or KDE. In my .profile I have the following commands:

Code: Select all

method=fcitx
export GTK_IM_MODULE=$method
export XMODIFIERS=@im=$method
export QT_IM_MODULE=$method
# ibus-daemon -xd
xmodmap -e 'keysym Mode_switch = Mode_switch Alt_R'

As you can see, I'm ready to switch framework at the drop of a hat.

Posted: **Tue Nov 26, 2019 3:43 pm**

Richard W wrote: ↑Tue Nov 26, 2019 12:30 pm
bradrn wrote: ↑Mon Nov 25, 2019 8:37 pm Thanks! I’m still a bit confused about m17n though: from the documentation, it looks more like a text manipulation library rather than a keyboard layout creation library. Could you explain how I can use it to make keyboards?
Monkey see, money do is the best way to get started. If you've got m17n-db set up, running it will tell you the name of the directory containing the system M17n data files. User data files go in the directory ~/.m17n.d. All the data files are text files. The keyboard layout definitions are the .mim files. They look like lisp (Lots of Irritating Silly Parentheses), but By default, what you type is what you get. Semicolons introduce end-of-line comments - but with the naughty habit of having directives within comments.

The file latn1-pre.mim gives you the sort of thing one typically does with dead keys - under the heading 'dead keys'. Now, this keyboard doesn't hide the dead key - if you press the key, you see something. but it gives you the dead key functionality. It also has the AltGr capability with 'AltGR/t yields thorn' implemented by the line "((G-t) ?þ)". This line is a production of 'RULE in the syntax definition.

That sounds simple enough. I don’t have m17n-db set up yet, but I assume it’s just sudo apt install m17n-db or something similar.

So, you edit the file, put it in the correct directory, and induce the framework to use it. Oh, and you set up environment variables so all the processes know which framework you want to use. The method of inducing is a bit unstable - you may need to ask for your particular distribution, quoting version and desktop manager, e.g. Gnome or KDE. In my .profile I have the following commands:
Code: Select all
method=fcitx
export GTK_IM_MODULE=$method
export XMODIFIERS=@im=$method
export QT_IM_MODULE=$method
# ibus-daemon -xd
xmodmap -e 'keysym Mode_switch = Mode_switch Alt_R'
As you can see, I'm ready to switch framework at the drop of a hat.

On the other hand, this sounds quite a bit trickier. I don’t like the sound of ‘unstable’… Also, what happens if I regularly switch between two window managers? I’ve been switching back and forth between XMonad, for the convenience and speed, and the default Ubuntu window manager (forgot what it’s called), because it can be easier to set up keyboard stuff there.

Posted: **Tue Nov 26, 2019 4:55 pm**

bradrn wrote: ↑Tue Nov 26, 2019 3:43 pm
Richard W wrote: ↑Tue Nov 26, 2019 12:30 pm Monkey see, money do is the best way to get started. If you've got m17n-db set up, running it will tell you the name of the directory containing the system M17n data files.
That sounds simple enough. I don’t have m17n-db set up yet, but I assume it’s just sudo apt install m17n-db or something similar.

Yes. The m17n-db package includes the m17n-db command to tell you where the files were put.

bradrn wrote: ↑Tue Nov 26, 2019 3:43 pm
Richard W wrote: ↑Tue Nov 26, 2019 12:30 pm So, you edit the file, put it in the correct directory, and induce the framework to use it. Oh, and you set up environment variables so all the processes know which framework you want to use. The method of inducing is a bit unstable - you may need to ask for your particular distribution, quoting version and desktop manager, e.g. Gnome or KDE.
On the other hand, this sounds quite a bit trickier. I don’t like the sound of ‘unstable’… Also, what happens if I regularly switch between two window managers? I’ve been switching back and forth between XMonad, for the convenience and speed, and the default Ubuntu window manager (forgot what it’s called), because it can be easier to set up keyboard stuff there.

The instability is certainly one incentive to not upgrade regularly. As to switching, it depends whether the systems share a common database. If the two systems have separate databases, then it will be like having two machines. When I was using a Windows XP desktop as an X-terminal, I'd invoke one of the Gnome start-up scripts from the terminal window so that I had access to the IBus keyboard selection.

Posted: **Wed Nov 27, 2019 1:36 am**

Richard W wrote: ↑Tue Nov 26, 2019 4:55 pm
bradrn wrote: ↑Tue Nov 26, 2019 3:43 pm
Richard W wrote: ↑Tue Nov 26, 2019 12:30 pm So, you edit the file, put it in the correct directory, and induce the framework to use it. Oh, and you set up environment variables so all the processes know which framework you want to use. The method of inducing is a bit unstable - you may need to ask for your particular distribution, quoting version and desktop manager, e.g. Gnome or KDE.
On the other hand, this sounds quite a bit trickier. I don’t like the sound of ‘unstable’… Also, what happens if I regularly switch between two window managers? I’ve been switching back and forth between XMonad, for the convenience and speed, and the default Ubuntu window manager (forgot what it’s called), because it can be easier to set up keyboard stuff there.
The instability is certainly one incentive to not upgrade regularly. As to switching, it depends whether the systems share a common database. If the two systems have separate databases, then it will be like having two machines. When I was using a Windows XP desktop as an X-terminal, I'd invoke one of the Gnome start-up scripts from the terminal window so that I had access to the IBus keyboard selection.

What exactly do you mean by ‘database’ here? As you may have gathered from this conversation, I don’t know all that much about this stuff.

(Also, to confirm that we’re talking about the same thing, are you using the term ‘window manager’ in the same sense as this article? If you are, then why would the keyboard layout setup depend on the choice of window manager?)

Posted: **Wed Nov 27, 2019 2:53 am**

bradrn wrote: ↑Wed Nov 27, 2019 1:36 am What exactly do you mean by ‘database’ here? As you may have gathered from this conversation, I don’t know all that much about this stuff.

(Also, to confirm that we’re talking about the same thing, are you using the term ‘window manager’ in the same sense as this article? If you are, then why would the keyboard layout setup depend on the choice of window manager?)

I though I'd corrected myelf to say 'desktop manager', because I mean a different concept. I'm thinking more along the lines of Gnome v. KDE. Gnome stores a lot of configuration data, and the keyboard picklist seems to be amongst it. The input framework is also amongst it - the environment variables have to accord with the selection or else significant parts of the fancy keyboard system stops working. As I say, the worst likely outcome of any switching is that you have to maintain two sets of setup information - and it may not happen. The frameworks may store their data independently of the desktop system. Indeed, some of the instability may be the result of a turf war between the two - who maintains the list?

Posted: **Wed Nov 27, 2019 3:03 am**

Richard W wrote: ↑Wed Nov 27, 2019 2:53 am
bradrn wrote: ↑Wed Nov 27, 2019 1:36 am What exactly do you mean by ‘database’ here? As you may have gathered from this conversation, I don’t know all that much about this stuff.

(Also, to confirm that we’re talking about the same thing, are you using the term ‘window manager’ in the same sense as this article? If you are, then why would the keyboard layout setup depend on the choice of window manager?)
I though I'd corrected myelf to say 'desktop manager', because I mean a different concept. I'm thinking more along the lines of Gnome v. KDE. Gnome stores a lot of configuration data, and the keyboard picklist seems to be amongst it. The input framework is also amongst it - the environment variables have to accord with the selection or else significant parts of the fancy keyboard system stops working. As I say, the worst likely outcome of any switching is that you have to maintain two sets of setup information - and it may not happen. The frameworks may store their data independently of the desktop system. Indeed, some of the instability may be the result of a turf war between the two - who maintains the list?

Oh, sorry, I didn’t notice you said ‘desktop manager’. That is indeed a totally different concept, and I can easily see how that affects the keyboard layout. I think I’m using GNOME, so I’ll go with that. Hopefully I’ve got all that figured out now — I’ll ask again if I run into any more difficulties.

Posted: **Wed Nov 27, 2019 5:34 am**

Well, I’ve sort of got ibus/m17n working: I successfully installed it and started the daemon, and can see the new keyboard layouts and use them successfully. I can even define my own keyboard layout and install it! However, I can’t find a program which accepts AltGr successfully: both gedit and Terminal (in this case the GNOME terminal) treat AltGr like an ordinary keyboard shortcut instead of inserting the special character defined for that key. Does anyone have any ideas?

Posted: **Wed Nov 27, 2019 10:06 am**

I don't know how that's solved of course, but I imagine it either has to do with M17n or maybe some misconfiguration somewhere... IBus and GNOME Terminal have no problems using with a distinct AltGr in the provided US-international and Spanish keyboards.

Posted: **Wed Nov 27, 2019 12:34 pm**

Ser wrote: ↑Wed Nov 27, 2019 10:06 am I don't know how that's solved of course, but I imagine it either has to do with M17n or maybe some misconfiguration somewhere... IBus and GNOME Terminal have no problems using with a distinct AltGr in the provided US-international and Spanish keyboards.

I think that is the reason for

Code: Select all

xmodmap -e 'keysym Mode_switch = Mode_switch Alt_R'

in my .profile. The definition of the US-international keyboard in /usr/share/X11/xkb/symbols/us contains the critical

Code: Select all

include "level3(ralt_switch)"

to include the definition from /usr/share/X11/xkb/symbols/level3.

Posted: **Wed Nov 27, 2019 1:33 pm**

Richard W wrote: ↑Tue Nov 26, 2019 4:55 pm The instability is certainly one incentive to not upgrade regularly. As to switching, it depends whether the systems share a common database. If the two systems have separate databases, then it will be like having two machines. When I was using a Windows XP desktop as an X-terminal, I'd invoke one of the Gnome start-up scripts from the terminal window so that I had access to the IBus keyboard selection.

I've just found the wonderful gem that in Ubuntu 18.04, Gnome won't allow one to select a keyboard unless the local for it is installed. While that won't affect Conkey, which declares itself for English, that's a bit awkward for a hieroglyphic keyboard or even a Lanna script keyboard. I didn't find evidence that this bug has been corrected. I suppose it's back to the lying that Windows insists on.

Posted: **Wed Nov 27, 2019 4:33 pm**

I got a bit nervous of pushing my advice beyond what I had actually done, so I went ahead and did the translation as proof of principle. It's currently available at http://wrdingham.co.uk/sounds/Conkey.mim . I'll probably take it down when the official conversion becomes available. Testing has been sketchy, and it contains typos. There are no deliberate errors.

I learnt two things during the process - hex numbers must start '0x'. not '0X' - and that if there are syntax errors, the keyboard file will be interpreted up to the point at which it deviated from the syntax.

I haven't addressed 'caps lock' - there might be a lot of work to do there. Also, as I said earlier, the dead keys aren't dead. I believe one can use states to implement them if one really wants dead key behaviour. After all, the M17n formalism seems to be designed to support, inter alia, the implementation of a Japanese IME.

AltGr worked for me - but then I patched fcitix to stop it deliberately ignoring it. I use it on Ubuntu 16.04. For later releases, one would, it seems, be back to IBus. At least package ibus-m17n has been reinstated.

As English is a known language, it was fairly straightforward to add the keyboard. I clicked 'configure' on the fcitix control button, and then the button labelled '+' to add the keyboard. There is another button to control whether it be added for 'other' languages. In general, there's the subtlety that keyboards are ordered by language code, so unknown codes are in alphabetical order but displayed as 'unknown'. M17n keyboards are further identified by (M17N) being added after the name form the keyboard file.

Zompist Bboard Again

[v5.2.0 now out] Conkey keyboard layout

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]

Re: Conkey keyboard layout [v1.1.0 now out!]