5 ms·

Not really. I don't know in advance which symbols I want to type, and even then I'd have to learn where I put the symbols on the custom layout, while the compos

by jtvjan 5y ago

Not really. I don't know in advance which symbols I want to type, and even then I'd have to learn where I put the symbols on the custom layout, while the compose sequences I can usually guess. Considering the amount of background processes the typical Windows system runs, having one additional program really doesn't make a difference.

shawnz 5y ago
I don't necessarily mean that each individual user of the software should do this. I mean, why not just create a new layout instead of developing this? Or as a user, why not just use a layout someone else has already developed which has logical choices for the composed keys? EDIT: Some compelling arguments in favour of the app in this thread. Thank you
- sterlind 5y ago
  you can't compose keyboard layouts, so you'd either have to stick with only QWERTY or generate separate enhanced layouts for Azerty + Dvorak + etc. discoverability would also be harder, and you'd have to hold down every key in the combo instead of pressing them in sequence holding the compose key, so you couldn't distinguish /ae/ vs /ea/ and you'd get carpal tunnel. side-note: X11 layouts are really frustrating. there's a hard constraint of one key combo -> one Unicode character, which makes it impossible to output multiple characters. I run into this with Lushootseed, which has /ƛ̕/ (glottalized barred lambda encoded as barred lambda + accent marker), but you'd never write it without the accent in that language.
  - bmn__ 5y ago
    > there's a hard constraint of one key combo -> one Unicode character, which makes it impossible to output multiple characters. The orthodox solution for this problem is an IME. Quickest path to success is via editing a new map file /usr/share/m17n/lut.mim (see Blackfoot and Inuktitut in the same directory for examples of multiple character output) and then using the m17n plugin for fcitx or scim or ibus.
- frosted-flakes 5y ago
  Because a Compose key allows you to type any of thousands of characters, which (a) isn't possible with a custom keyboard layout, and even if it was, (b) would be very difficult to learn.
  - shawnz 5y ago
    What makes this easier to learn? I think you could implement the same kinds of sequences by using AltGr combined with dead keys.
    - frosted-flakes 5y ago
      So you're going to turn every key on the keyboard into a dead key? Also, the compose file can easily be customized, and some entries output multiple characters or involve non-character keys like the arrows. How is that going to work with a static keyboard layout?
      - shawnz 5y ago
        Only AltGr + [the key] would be a dead key, not the bare key itself. Perhaps a tool could be made to convert compose files into Windows keyboard layout definitions with this strategy That's a good point about non-character keys though, I don't think that could be supported with this method.
      - account42 5y ago
        > some entries output multiple characters Too bad that Qt broke support for that in version 5 and has never fixed it.
- Symbiote 5y ago
  You'd swiftly run out of practical combinations. On the 1 key, I have 1 and !. Maybe I could add ¹ and ₁, with AltGr and Shift+AltGr (or Ctrl, or something). Maybe ½ and ¼? With Compose, I have ¹, ₁, ½, ⅓, ¼, ⅕, ⅙, ⅐, ⅛, ⅑, ⅒, ①, ⑩, ⑪, … ㊶ which involve the 1 key. I do not need to look up the sequences for these, as they're intuitive: Compose ^ 1, Compose _ 1, Compose 1 2, … Compose ( 4 1 ).
  - shawnz 5y ago
    You could maybe use AltGr combined with dead keys to accomplish that, but I suppose it would be limited to combinations of two keys (plus the modifier). EDIT: Actually, it seems Windows supports chained dead keys, so I think you could accomplish longer sequences with a plain old Windows keyboard layout definition too. But that's not supported with MSKLC.

by jtvjan 5y ago

shawnz 5y ago

I don't necessarily mean that each individual user of the software should do this. I mean, why not just create a new layout instead of developing this? Or as a user, why not just use a layout someone else has already developed which has logical choices for the composed keys? EDIT: Some compelling arguments in favour of the app in this thread. Thank you

sterlind 5y ago
you can't compose keyboard layouts, so you'd either have to stick with only QWERTY or generate separate enhanced layouts for Azerty + Dvorak + etc. discoverability would also be harder, and you'd have to hold down every key in the combo instead of pressing them in sequence holding the compose key, so you couldn't distinguish /ae/ vs /ea/ and you'd get carpal tunnel. side-note: X11 layouts are really frustrating. there's a hard constraint of one key combo -> one Unicode character, which makes it impossible to output multiple characters. I run into this with Lushootseed, which has /ƛ̕/ (glottalized barred lambda encoded as barred lambda + accent marker), but you'd never write it without the accent in that language.
- bmn__ 5y ago
  > there's a hard constraint of one key combo -> one Unicode character, which makes it impossible to output multiple characters. The orthodox solution for this problem is an IME. Quickest path to success is via editing a new map file /usr/share/m17n/lut.mim (see Blackfoot and Inuktitut in the same directory for examples of multiple character output) and then using the m17n plugin for fcitx or scim or ibus.
frosted-flakes 5y ago
Because a Compose key allows you to type any of thousands of characters, which (a) isn't possible with a custom keyboard layout, and even if it was, (b) would be very difficult to learn.
- shawnz 5y ago
  What makes this easier to learn? I think you could implement the same kinds of sequences by using AltGr combined with dead keys.
  - frosted-flakes 5y ago
    So you're going to turn every key on the keyboard into a dead key? Also, the compose file can easily be customized, and some entries output multiple characters or involve non-character keys like the arrows. How is that going to work with a static keyboard layout?
    - shawnz 5y ago
      Only AltGr + [the key] would be a dead key, not the bare key itself. Perhaps a tool could be made to convert compose files into Windows keyboard layout definitions with this strategy That's a good point about non-character keys though, I don't think that could be supported with this method.
    - account42 5y ago
      > some entries output multiple characters Too bad that Qt broke support for that in version 5 and has never fixed it.
Symbiote 5y ago
You'd swiftly run out of practical combinations. On the 1 key, I have 1 and !. Maybe I could add ¹ and ₁, with AltGr and Shift+AltGr (or Ctrl, or something). Maybe ½ and ¼? With Compose, I have ¹, ₁, ½, ⅓, ¼, ⅕, ⅙, ⅐, ⅛, ⅑, ⅒, ①, ⑩, ⑪, … ㊶ which involve the 1 key. I do not need to look up the sequences for these, as they're intuitive: Compose ^ 1, Compose _ 1, Compose 1 2, … Compose ( 4 1 ).
- shawnz 5y ago
  You could maybe use AltGr combined with dead keys to accomplish that, but I suppose it would be limited to combinations of two keys (plus the modifier). EDIT: Actually, it seems Windows supports chained dead keys, so I think you could accomplish longer sequences with a plain old Windows keyboard layout definition too. But that's not supported with MSKLC.