kmfl-user Mailing List for Keyboard Mapping for Linux
Brought to you by:
courtjester
Menu
▾
▴
kmfl-user — Discuss anything about how to install and use KMFL
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(7) |
|
From: Richard W. <ric...@nt...> - 2016-12-13 07:39:23
|
On Sun, 11 Dec 2016 11:38:13 +0000 Richard Wordingham <ric...@nt...> wrote: > My 'physical' KMFL keyboard has not survived the transition from > Ubuntu 12.04 Precise to Ubuntu 16.04 Xenial as well as I thought. On reviewing the KMfL code, I now see that there currently isn't any difference between a physical and a mnemonic *KMfL* keyboard. > What seems odd is that KMfL used the scan code to distinguish the > inputs [K_oE2] and [shift K_COMMA], but not [shift K_oE2] and [shift > K_PERIOD]. Unfortunately, the KMfL interpreter simply ignores the scan code. What it looks at is the key symbol and the shift state. Thus the first pair is distinguish because of different shift state - '<' without and with shift, but the second pair is just received as '>' with shift, and I'm lucky that it is translated to U+1A4A (for which I have set up no alternative keying) and not U+1A55 (for which I do have an alternative keying). The key observation is that KMfL does not support [shift K_oE2] for the US keyboard setting. Richard. |
|
From: Richard W. <ric...@nt...> - 2016-12-11 11:38:21
|
My 'physical' KMFL keyboard has not survived the transition from Ubuntu
12.04 Precise to Ubuntu 16.04 Xenial as well as I thought. To fix
other problems, the underlying XKB is the US keyboard. This could
potentially cause problems with the international-backspace key, which
is not on modern US keyboards (but could be found on the VT100), but
has been partially addressed in KMfL. It is the key between shift_L
and 'Z' on the UK keyboard. It has the same symbols on it on a UK
keyboard as does the US backslash key on a US keyboard.
My problem is that while plain international-backslash keyboard
delivers the right character, shift-international backslash does not.
Now, the international-backslash keyboard is purely a convenience; the
characters I have put on it can also be obtained by custom dead-key
sequences. (They're dead key sequences because I couldn't get AltGr to
work.)
The relevant parts of my KMfL file, lanna3.kmn of 21 November 2016, are:
VERSION 6.0 c For Keyman 6.0 or later.
Name "Lanna Unicode"
Bitmap "lanna.png"
store(&MnemonicLayout) "0" C Physical
store(&language) "nod"
Author "Richard Wordingham"
Copyright "Copyright ©2006, 2010 Richard Wordingham"
Message "Extended Kedmanee for Lanna"
Begin Unicode > use(Main)
group(Main) using keys
+ [K_oE2] > U+1a40 c TAI THAM LETTER HIGH YA
+ [shift K_oE2] > U+1a55 c TAI THAM CONSONANT SIGN MEDIAL RA
+ [K_BKSLASH] > U+1a22 c TAI THAM LETTER HIGH KXA
+ [shift K_BKSLASH] > U+1a24 c TAI THAM LETTER LOW KXA
+ [shift K_COMMA] > U+1a30 c TAI THAM LETTER LOW RATHA
+ [shift K_PERIOD] > U+1a4a c TAI THAM LETTER LLA
I entered the 6-'character' sequence, as depicted on my UK keyboard,
"\|#~<>". I released the shift key after each pair of 'characters'.
What I expected to get was the character sequence <U+1A40, U+1A55,
U+1A22, U+1A24, U+1A30, U+1A4A>. However, I get U+1A4A instead of
U+1A55.
I monitored the keypress inputs using a modification of Xev and got the
following sequence. Only the string values returned surprise me. I
used XwcLookupString to get the string values.
IM devoured scan code 94, state 0000, key <, char <
Received scan code 0, state 0000, key 0000, char 0000 - string U+1A40
IM devoured scan code 62, state 0000, key 0xffe2, char 0xffe2
Received scan code 62, state 0000, key 0xffe2, char 0xffe2 - keysym
0xffe2
IM devoured scan code 94, state 0001, key <, char >
Received scan code 0, state 0000, key 0000, char 0000 - string U+1A4A
IM devoured scan code 51, state 0000, key \, char \
Received scan code 0, state 0000, key 0000, char 0000 - string U+1A22
IM devoured scan code 62, state 0000, key 0xffe2, char 0xffe2
Received scan code 62, state 0000, key 0xffe2, char 0xffe2 - keysym
0xffe2
IM devoured scan code 51, state 0001, key \, char |
Received scan code 0, state 0000, key 0000, char 0000 - string U+1A24
IM devoured scan code 62, state 0000, key 0xffe2, char 0xffe2
Received scan code 62, state 0000, key 0xffe2, char 0xffe2 - keysym
0xffe2
IM devoured scan code 59, state 0001, key ,, char <
Received scan code 0, state 0000, key 0000, char 0000 - string U+1A30
IM devoured scan code 60, state 0001, key ., char >
Received scan code 0, state 0000, key 0000, char 0000 - string U+1A4A
In the above, 'IM devoured' means that the event was filtered out by
XFilterEvent().
What seems odd is that KMfL used the scan code to distinguish the inputs
[K_oE2] and [shift K_COMMA], but not [shift K_oE2] and [shift K_PERIOD].
Richard.
|
|
From: Richard W. <ric...@nt...> - 2016-12-10 12:28:52
|
On Sat, 10 Dec 2016 10:25:24 +0000 Richard Wordingham <ric...@nt...> wrote: > I have seen suggestions that users edit the user IBus reɡistry in > ~/.cache/ibus/bus to select the underlyinɡ XKB keyboard. However, > that has changed from a text to a binary file. That does actually seem to work. I changed 'us' to 'gb' usinɡ emacs as a 'hex' editor. To be precise: Step 1: Examine the registry using a suitable command such as ibus read-cache | grep -B3 -A10 XSAMPA to see what text is associated with the XSAMPA keyboard Step 2: Open ~/.cache/ibus/bus in emacs. Step 3: Ensure lines are wrapped, e.g. by using the options menu. Step 4: Find the string XSAMPA, e.g. by invoking incremental search by ctrl-S. Step 5: Find the 2-letter string "us" flanked by "^@". Step 6: Replace it by "gb". Step 7: Save the file (e.g. by ctrl-X ctrl-S). Step 8: In a command window, issue the command "ibus-daemon -rxd" to update IBus. The edited cache survives at least logging out and logging in. It's fairly straightforward to clone KMFL keyboards if one needs to support different keyboard labellings. One just copies the .kmn files. Replacing this procedure by a sound process is an IBus issue. Richard. |
|
From: Richard W. <ric...@nt...> - 2016-12-10 10:25:38
|
On Fri, 9 Dec 2016 09:54:16 -0800 Doug Rintoul <dou...@si...> wrote: > The bug you are describing is definitely related to ibus rather than > kmfl specifically. Are you saying that purging libibus-1.0-0 fixed > the problem for you? It is possible that libibus-1.0-0 had a bug that > would not allow using the system keyboard for ibus keyboards. The > weird thing is "Input Bus - rc libibus-1.0-0: 1.4.1-3ubunt i386" > indicates that libibus-1.0-0 was not installed on your system but > there was still configuration files kicking around. That is what the > "rc" indicates. Purging libibus-1.0-0 would delete those > configuration files. So it may be that those files were interfering > with libibus-1.0-5: 1.5.11 operation. The purge seems to have restored some functionality, to what I had in Ubuntu Precise. The mnemonic keyboard I use is for entering IPA using XSAMPA keystrokes. That uses backslash (\) to double up the number of characters, and I extended the concept to add extra options ́(e.g tone accents v. tone letters) by lettinɡ backslash cycle throuɡh a list of options, a trick I copied from Martin Hosken). Before the purge, I only had the backslash in the US position. Now, the keyboards I currently have enabled are, in order: UK English (straight from XKB) Thai (TIS 820.2538) (straight from XKB) Khmer (straight from XKB) US Enɡlish (straight from XKB) Lanna Unicode (my own positional KMfL keyboard) XSAMPA (my own menmonic KMfL keyboard) Romaja (An M17n Korean keyboard) After a while, switching to IBus keyboards does not work - I get only the US keyboard. I have to restart the daemon (ibus-daemon -rxd) even though no daemons seem to have died. I'm beginning to wonder if there is some time-out on the switching ability. This was the state of affairs both before and after the purge. Shortly after logging in or restarting the IBus daemon, starting or switching to a new application makes XSAMPA keyboard the active keyboard. The system keyboard, a plain XKB keyboard, is the first keyboard in my list of keyboards. If I wait long enough, this behaviour seems to go away. The keyboard indicator shows that I am using the plain XKB keyboard, but recently there has also been an undocked keyboard indicator. This undocked indicator started appearing before the purge. (Is there a shortcut to switch to the indicated keyboard?) As I reviewed this reply, I observed that if I switched to the XSAMPA keyboard by switching focus between applications, backslash is on the ‘international backslash’ key on the left. However, if I switch using the keyboard indicator or the ‘hot keys’, the backslash is positioned according to the US keyboard, next to the return key. Thus the fix is less complete than I had thought, but provides a useful functionality for me, as I currently use only one mnemonic keyboard. The general picture is that IBus is nowadays somewhat broken, but usable by the patient. So, how do physical and mnemonic KMfL keyboard mappings determine what character or keystroke is to be fed into the KMfL engine defined by the .kmn file? My understanding is that the physical keyboard relies on something close to the US keyboard being the XKB map at some stage, but I am not sure what it is that selects a US keyboard map. The KMfL engine at least manages to identify the international backslash key in physical keyboards - key stroke [K_oE2]. The old keyboarding system, as in Ubuntu Precise, allowed fine control. One could chose an XKB mapping to correspond to the actual markings on the keys for the peek and peck users, and then the IME could be chosen to reinterpret the corresponding key strokes. Thus, for my XSAMPA keyboard, one could just remember a rule such as "'@' gives you 'ə'", rather than having to remember "[shift K_2] gives you 'ə'". (I have both UK and Thai keyboards in the house, and the Thai keyboard is engraved for a US layout.) I have seen suggestions that users edit the user IBus reɡistry in ~/.cache/ibus/bus to select the underlyinɡ XKB keyboard. However, that has changed from a text to a binary file. Richard. |
|
From: Doug R. <dou...@si...> - 2016-12-09 18:17:45
|
On 2016-12-09 02:17 AM, Richard Wordingham wrote: > On Mon, 5 Dec 2016 07:42:35 +0000 > Richard Wordingham <ric...@nt...> wrote: > >> My problem with mnemonic keyboards is that they do not work well as >> menmonic keyboards. They interpret my keystrokes as though I were >> using a US keyboard rather than a UK keyboard. Is there a solution, >> and if not, will there be one, or is the portable mnemonic keyboard >> dead? In 'IBus preferences', accessed by command 'ibus-setup', 'use >> system keyboard layout' is ticked. >> >> dpkg -l reports: >> >> ii ibus-kmfl 1.0.8-2+xeni i386 kmfl engine for IBus >> ii kmfl-keyboard- 1.4ibus-1ubu all KMFL keyboard for IPA >> ii kmflcomp 0.9.10-2+xen i386 KMFL (Keyboard Mapping >> for ii libkmfl0 0.9.12-1+xen i386 A Library for >> providing ii libkmflcomp0 0.9.10-2+xen i386 KMFL (Keyboard >> Mapping for ii gir1.2-ibus-1. 1.5.11-1ubun i386 Intelligent >> Input Bus - ii ibus 1.5.11-1ubun i386 Intelligent >> Input Bus - ii libibus-1.0-5: 1.5.11-1ubun i386 Intelligent >> Input Bus - rc libibus-1.0-0: 1.4.1-3ubunt i386 Intelligent >> Input Bus - ii ibus-gtk:i386 1.5.11-1ubun i386 Intelligent >> Input Bus - ii ibus-gtk3:i386 1.5.11-1ubun i386 Intelligent >> Input Bus - > There appears to be a solution to this problem, though I don't > understand it how works. It was given by Daniil Ivanov in > https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1235991 on 26 May > 2014. It is to run the command "apt-get purge libibus-1.0-0". > > The solution probably depends on having 'use system keyboard layout' > ticked in the 'advanced' tab of IBus Preferences, which is accessible > by running the allegedly obsolete command ibus-setup. > > While the implication of the original suggestion is that it worked for > Anthy, and I have found it to work for KMfL, it seems that it doesn't > work for M17n, at least, not for the Korean-input method Romaja. > > Richard. > > Hi Richard, The bug you are describing is definitely related to ibus rather than kmfl specifically. Are you saying that purging libibus-1.0-0 fixed the problem for you? It is possible that libibus-1.0-0 had a bug that would not allow using the system keyboard for ibus keyboards. The weird thing is "Input Bus - rc libibus-1.0-0: 1.4.1-3ubunt i386" indicates that libibus-1.0-0 was not installed on your system but there was still configuration files kicking around. That is what the "rc" indicates. Purging libibus-1.0-0 would delete those configuration files. So it may be that those files were interfering with libibus-1.0-5: 1.5.11 operation. Let me know if I can be of more assistance. Cheers, Doug. |
|
From: Richard W. <ric...@nt...> - 2016-12-09 10:17:40
|
On Mon, 5 Dec 2016 07:42:35 +0000 Richard Wordingham <ric...@nt...> wrote: > My problem with mnemonic keyboards is that they do not work well as > menmonic keyboards. They interpret my keystrokes as though I were > using a US keyboard rather than a UK keyboard. Is there a solution, > and if not, will there be one, or is the portable mnemonic keyboard > dead? In 'IBus preferences', accessed by command 'ibus-setup', 'use > system keyboard layout' is ticked. > > dpkg -l reports: > > ii ibus-kmfl 1.0.8-2+xeni i386 kmfl engine for IBus > ii kmfl-keyboard- 1.4ibus-1ubu all KMFL keyboard for IPA > ii kmflcomp 0.9.10-2+xen i386 KMFL (Keyboard Mapping > for ii libkmfl0 0.9.12-1+xen i386 A Library for > providing ii libkmflcomp0 0.9.10-2+xen i386 KMFL (Keyboard > Mapping for ii gir1.2-ibus-1. 1.5.11-1ubun i386 Intelligent > Input Bus - ii ibus 1.5.11-1ubun i386 Intelligent > Input Bus - ii libibus-1.0-5: 1.5.11-1ubun i386 Intelligent > Input Bus - rc libibus-1.0-0: 1.4.1-3ubunt i386 Intelligent > Input Bus - ii ibus-gtk:i386 1.5.11-1ubun i386 Intelligent > Input Bus - ii ibus-gtk3:i386 1.5.11-1ubun i386 Intelligent > Input Bus - There appears to be a solution to this problem, though I don't understand it how works. It was given by Daniil Ivanov in https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1235991 on 26 May 2014. It is to run the command "apt-get purge libibus-1.0-0". The solution probably depends on having 'use system keyboard layout' ticked in the 'advanced' tab of IBus Preferences, which is accessible by running the allegedly obsolete command ibus-setup. While the implication of the original suggestion is that it worked for Anthy, and I have found it to work for KMfL, it seems that it doesn't work for M17n, at least, not for the Korean-input method Romaja. Richard. |
|
From: Richard W. <ric...@nt...> - 2016-12-05 07:42:46
|
I've recently moved on from Ubuntu Precise to Ubuntu Xenial. There have been a number of problems, which might possibly relate to my specific problem with mnemonic keyboards. I'm having trouble using my KMFL keyboards via ibus in non-GTK3 applications. I'm having to issue the command ibus-daemon -rxd before the keyboards will work, despite having ibus-daemon -xd in ~/.profile. That command seems to be being executed, for 'ps -efc | grep ibus' shows the command 'ibus-daemon -xd' is still active in some fashion. I also had to create a shortcut ~/.kmfl/icon to ~/.kmfl/icons for my KMFL keyboards to work. (I only discovered the solution by running ibus-setup.) My problem with mnemonic keyboards is that they do not work well as menmonic keyboards. They interpret my keystrokes as though I were using a US keyboard rather than a UK keyboard. Is there a solution, and if not, will there be one, or is the portable mnemonic keyboard dead? In 'IBus preferences', accessed by command 'ibus-setup', 'use system keyboard layout' is ticked. dpkg -l reports: ii ibus-kmfl 1.0.8-2+xeni i386 kmfl engine for IBus ii kmfl-keyboard- 1.4ibus-1ubu all KMFL keyboard for IPA ii kmflcomp 0.9.10-2+xen i386 KMFL (Keyboard Mapping for ii libkmfl0 0.9.12-1+xen i386 A Library for providing ii libkmflcomp0 0.9.10-2+xen i386 KMFL (Keyboard Mapping for ii gir1.2-ibus-1. 1.5.11-1ubun i386 Intelligent Input Bus - ii ibus 1.5.11-1ubun i386 Intelligent Input Bus - ii libibus-1.0-5: 1.5.11-1ubun i386 Intelligent Input Bus - rc libibus-1.0-0: 1.4.1-3ubunt i386 Intelligent Input Bus - ii ibus-gtk:i386 1.5.11-1ubun i386 Intelligent Input Bus - ii ibus-gtk3:i386 1.5.11-1ubun i386 Intelligent Input Bus - Richard. |
|
From: Richard W. <ric...@nt...> - 2013-08-12 21:36:48
|
On Mon, 12 Aug 2013 10:51:50 -0700 Doug Rintoul <dou...@si...> wrote: > On 13-08-11 05:22 PM, Richard Wordingham wrote: > > As a result of moving from Ubuntu 10.04 Lucid Lynx to Ubuntu > > 12.04 Precise Pangolin, LibreOffice is no longer working properly > > with my KMFL keyboards run via iBus. > Thanks for your reports. Unfortunately, I am going to be away for the > next three weeks and will not have time to look at them until early > September. I am somewhat surprised at your report though since I am on > 12.04 and am using LibreOffice fine with kmfl. One question, what is > your XMODIFIER environment variable set to? It should be @im=ibus. If > it isn't, then make sure your Keyboard input method system is set to > IBUS. XMODIFIERS is set as specified in ~/.profile (and remains so in terminal windows), and I presume that it was you meant. The keyboard input method systems has remained at ibus since the 'upgrade'. Annoyingly, the error is unpredictable. In some editing sessions the errors occur, and in other they don't. I can't see any effect from how I launch LibreOffice. I fired it up from the command line (libreoffice&) and it worked fine, and then I repeated the experiment, and it didn't! I often get 'General error' from LibreOffice on opening an existing document, but there is no obvious problem related to this error. Where an additional keystroke just toggles characters, repeatedly striking the toggle does to seem work in the end. However, I do have some good news. Upgrading to LibreOffice 4.1 eliminates the problem! Richard. |
|
From: Richard W. <ric...@nt...> - 2013-08-12 19:26:12
|
On Sun, 11 Aug 2013 23:52:06 +0100 Richard Wordingham <ric...@nt...> wrote: > A week ago I moved from Ubuntu 10.04 (Lucid Lynx) to 12.04 (Precise > Pangolin) and I have now discovered subtle changes in the behaviour of > my Keyman for Linux keyboards has stopped working. Is it a permanent > change in interpretation, or a temporary aberration? I've finally found the major cause of the problem. It seems that iBus 1.4.1 will set the underlying keyboard to 'us' (as defined in /usr/share/ibus/keymaps/us and associated files, not by the XKB settings) if in the 'IBus Preferences' Advanced tab one does not tick the box 'Use system keyboard layout'. I've ticked that box, and thereby restored the previous operation for most applications. (I have a probably unrelated problem with LibreOffice 4.0.2.2.) Richard. |
|
From: Richard W. <ric...@nt...> - 2013-08-12 00:22:11
|
As a result of moving from Ubuntu 10.04 Lucid Lynx to Ubuntu 12.04 Precise Pangolin, LibreOffice is no longer working properly with my KMFL keyboards run via iBus. One problem applications have in interfacing with KMFL via an X input method is that the inputs are a mixture of character strings and deletion commands. Many applications simply ignore the deletion commands (e.g. gnome-terminal, the 'dash home' of Unity). LibreOffice (at 4.0.2.2) misorders them - when an input string b_< should be converted to ɓ, I see the 'ɓ' flash up, but then all I am left with at the screen and in the backing store is the single character 'b'. It appears that the new character is being applied before the last of the three deletions. The problem is a race condition, as can be seen when a single character toggles the previous character. Input is continuing to work in other applications, so I am fairly confident it is a LibreOffice bug. Is there an API definition I can reference in the bug report I need to raise on LibreOffice? I want to be able to give chapter and verse. Richard. |
|
From: Richard W. <ric...@nt...> - 2013-08-11 22:52:17
|
A week ago I moved from Ubuntu 10.04 (Lucid Lynx) to 12.04 (Precise
Pangolin) and I have now discovered subtle changes in the behaviour of
my Keyman for Linux keyboards has stopped working. Is it a permanent
change in interpretation, or a temporary aberration?
I updated my KMFL packages from the repository for Ubuntu lucid to
Ubuntu precise. According to the Synaptic package manager, the
versions for lucid I was using were the latest available.
The relevant new package versions are:
kmflcomp0 0.9.9-0ubuntu1.13
ibus-kmfl 1.0.7-0ubuntu1.13
The first problem is that mnemonic keyboards no longer seem to be
mnemonic and the second problem is that physical keyboards no longer
appear to be mnemonic. The Latin KBD keyboard that I use is a British
keyboard. This differs from the US keyboard in, amongst others, the
final particulars:
Unshifted UK shifted US shifted
2 " @
3 £ #
' @ "
In my physical keyboard 'Lanna Unicode', I have the following lines
(amongst others):
store(&MnemonicLayout) "0" C Physical
+ [shift K_2] > U+1A81 c TAI THAM HORA DIGIT ONE
+ [shift K_3] > U+1A82 c TAI THAM HORA DIGIT TWO
+ [shift K_QUOTE] > U+002e
+ [shift K_SPACE] > U+200b
Before the change, shift-2, shift-3 and shift-' yielded U+1A81,
U+1A82 and U+002E. After the change, they yield U+002E, U+0023 and
U+1A81. This key is no longer physical, but mnemonic! There is a
subtle distinction, though - shift-space still yields U+200B. The
interpretation seems to be based on the first keyboard mapping in
one's set of XKB keyboards, not the set current when the KMFL
keyboard is active.
In my mnemonic keyboard 'Lanna Unicode (UK)', I have the following
lines (amongst others):
store(&MnemonicLayout) "1" C Mnemonic
+ $QUOTE > U+1A81 c TAI THAM HORA DIGIT ONE
+ U+00A3 > U+1A82 c TAI THAM HORA DIGIT TWO
+ "@" > U+002e c FULL STOP
+ "#" > U+1a22 c TAI THAM LETTER HIGH KXA
Before the change, shift-2, shift-3 and shift-' yielded U+1A81,
U+1A82 and U+002E. After the change, they yield U+002E, U+1A22 and
U+1A81. It appears that the logic now proceeds:
shift-2 -> keysym @ -> U+002E
shift-3 -> keysym # -> U+1A22
shift-' -> keysym " -> U+1A81
This looks like a physical keyboard - converts strokes to keysyms by
US rules and then interprets the keysyms according to the data in the
layout file.
Richard.
|
|
From: Bèrto ëd S. <ber...@gm...> - 2009-10-30 21:23:17
|
Hi! I can't seem to find an online install guide. I'm running Fedora 11/KDE and I'd be okay with compiling from source, but I'd like to know a bit about what packages are needed, if any. Berto |
|
From: Doug R. <dou...@si...> - 2008-02-26 16:51:03
|
Alf Wernersson wrote: > Doug Rintoul skrev: >> Alf Wernersson wrote: >>> I have used Keyman to redefine my keyboard for esperanto for severel >>> years. Now I'm trying to change to Linux and was very happy when I >>> found KMFL. I have tried to follow installtion instructions found in >>> this mail list. I need detailed help how to install it in Fedora 8. >>> I'm totally newbie to Linux :-\ . >>> >>> Regards >>> Alf >> Hi Alf, >> >> The first thing to do is to make sure that SCIM is installed and >> running properly on Fedora 8. You can do this as follows: >> >> 1. Go to Applications/Add Remove Software >> 2. Click on the search tab and search for SCIM >> 3. Ensure the following are installed >> >> scim-bridge-gtk >> scim-bridge-qt >> scim-gtk >> scim-bridge-qt4 >> scim-libs >> scim-bridge >> scim >> >> 4. Once these packages are install go to >> System/Preferences/Personal/Input Method >> Make sure that "Enable input method" feature is checked and that SCIM >> is selected >> >> I am not sure but you may need to log off and back on again before >> you can do this. >> >> 5. Install kmfl rpms. >> >> I have just uploaded RPMs for kmfl to the sourceforge site. You can >> download them from >> >> http://sourceforge.net/project/showfiles.php?group_id=130915 >> >> The file you want is kmfl-0.9.6-fc8.tar.gz >> <http://downloads.sourceforge.net/kmfl/kmfl-0.9.6-fc8.tar.gz?modtime=1203960629&big_mirror=0>. >> >> >> The is a compressed archive which contains three RPMs. Let me know of >> you need help on how to install them. >> >> Once kmfl is installed, you will need to log off and back on again. >> You can then install kmfl keyboards from scim-setup. Right click on >> the SCIM icon in the tool tray and select SCIM setup. Expand the >> IMengine tree in the left pane and select KMFL. You can then manage >> keyboards by the buttons in the right pane. >> >> Let me know if you need more details. >> >> Doug. >> >> > Doug, Thank You very much for helping. > I have now installed all packages up to point 3. > When I do point 4 I get following message: > "No input method is available > Please install any input methods before running if you like." > > I have also downloaded the kmfl rpms, but not installed them yet. Do I > have to install them in a special order? > Hi Alf, You are almost there. You will have no input methods available because you have not installed any yet. SCIM provides the framework for input methods but you still have to install some. If you do another search for SCIM in the Add/Remove software, you will see a number of input methods available. Examples are scim-tables-thai, scim-tables-arabic, and scim-m17n. KMFL provides Keyman input methods to the SCIM framework. After you install KMFL and install your Esperanto keyboard via scim-setup, you should see it in the list of input methods. You should install the rpms in the following order. kmflcomp libkmfl scim-kmfl-imengine Hope this helps. BTW, kmfl only supports Keyman source files (kmn files). The binary format of Keyman is proprietary and so we cannot use it. Doug. |
|
From: Doug R. <dou...@si...> - 2008-02-25 17:45:36
|
Alf Wernersson wrote: > I have used Keyman to redefine my keyboard for esperanto for severel > years. Now I'm trying to change to Linux and was very happy when I found > KMFL. I have tried to follow installtion instructions found in this mail > list. I need detailed help how to install it in Fedora 8. I'm totally > newbie to Linux :-\ . > > Regards > Alf Hi Alf, The first thing to do is to make sure that SCIM is installed and running properly on Fedora 8. You can do this as follows: 1. Go to Applications/Add Remove Software 2. Click on the search tab and search for SCIM 3. Ensure the following are installed scim-bridge-gtk scim-bridge-qt scim-gtk scim-bridge-qt4 scim-libs scim-bridge scim 4. Once these packages are install go to System/Preferences/Personal/Input Method Make sure that "Enable input method" feature is checked and that SCIM is selected I am not sure but you may need to log off and back on again before you can do this. 5. Install kmfl rpms. I have just uploaded RPMs for kmfl to the sourceforge site. You can download them from http://sourceforge.net/project/showfiles.php?group_id=130915 The file you want is kmfl-0.9.6-fc8.tar.gz <http://downloads.sourceforge.net/kmfl/kmfl-0.9.6-fc8.tar.gz?modtime=1203960629&big_mirror=0>. The is a compressed archive which contains three RPMs. Let me know of you need help on how to install them. Once kmfl is installed, you will need to log off and back on again. You can then install kmfl keyboards from scim-setup. Right click on the SCIM icon in the tool tray and select SCIM setup. Expand the IMengine tree in the left pane and select KMFL. You can then manage keyboards by the buttons in the right pane. Let me know if you need more details. Doug. |
|
From: Alf W. <aw...@gl...> - 2008-02-22 21:04:17
|
I have used Keyman to redefine my keyboard for esperanto for severel years. Now I'm trying to change to Linux and was very happy when I found KMFL. I have tried to follow installtion instructions found in this mail list. I need detailed help how to install it in Fedora 8. I'm totally newbie to Linux :-\ . Regards Alf |
|
From: Goren <g0...@ma...> - 2006-10-22 17:19:47
|
Hello. Is anybody out there? I joined the list to discuss problems of KMFL development. I think the product is great! The only problem is lack of keyboards. Maybe there is any way to use (decode/decompile) keyman KMX keyboard files? Because it's really hard to find sources for them... |
