Bugzilla – Bug 105319
skim cannot be activated by both Control+Space *and* Shift+Space
Last modified: 2005-08-20 00:36:06 UTC
The skim package on SuSE Linux is configure to use both "Control+Space" *and* "Shift+Space" as trigger keys. On Beta2 I found that only Control+Space works, "Shift+Space" doesn't trigger skim. I played around with the skim setup dialog, without success. The current contents of the setup file are: linux@rossini:~> cat .kde/share/config/skimrc [MainWindow] /Panel/KDE/MainWindow/Position=0,500 [SCIM] /Hotkeys/FrontEnd/Trigger=Shift+Space,Control+space /UpdateTimeStamp=1124310691:584986 [SetupWindow] SetupWindowSize=799,513 linux@rossini:~> Nevertheless, "Shift+Space" still doesn't work. Restarting KDE doesn't help. When using only scim and not skim, it seems to work OK, I can configure both "Shift+Space" and "Control+Space" without problems in the setup dialog and it becomes effective immediatly, no need to restart neither scim nor the X11 session. So this problem seems to be skim specific.
pdb says you're the maintainer of skim
Of course.
Add skim author <liucougar@gmail.com> to CC:.
I found a typo in my config.spatch in the scim package to patch the default configuration. The patch looked like: diff -ru scim-1.4.1.orig/configs/config scim-1.4.1/configs/config --- scim-1.4.1.orig/configs/config 2005-06-26 18:35:08.000000000 +0200 +++ scim-1.4.1/configs/config 2005-08-10 12:40:41.000000000 +0200 @@ -1,5 +1,6 @@ # This file is encoded in UTF-8 encoding. /FrontEnd/OnTheSpot = true +/FrontEnd/SharedInputMethod = true /FrontEnd/ChangeFactoryGlobally = false /FrontEnd/Socket/ConfigReadOnly = false /FrontEnd/Socket/MaxClients = 512 @@ -10,7 +11,7 @@ /Hotkeys/FrontEnd/NextFactory = Control+Alt+Down,Shift+Control+KeyRelease+Shift_L,Shift+Control+KeyRelease+Shift_R /Hotkeys/FrontEnd/PreviousFactory = Control+Alt+Up,Shift+Control+KeyRelease+Control_L,Shift+Control+KeyRelease+Control_R /Hotkeys/FrontEnd/ShowFactoryMenu = Control+Alt+Right -/Hotkeys/FrontEnd/Trigger = Control+space +/Hotkeys/FrontEnd/Trigger = Control+space,Shift+Space /Hotkeys/FrontEnd/ValidKeyMask = Shift+Control+Alt+CapsLock+Meta /Panel/Gtk/Color/ActiveBackground = light sky blue /Panel/Gtk/Color/ActiveText = black scim-1.4.1/configsだけに発見: config.orig But it should be "Shift+space" not "Shift+Space". I'll fix this now and check whether this makes a difference for skim.
I tried to add Shift+space, and it works with skim immediately
After fixing this bug in our scim configuration, I can use both Control+space and Shift+space to activate skim (fix submitted to STABLE, should be in the next beta). So my typo definitely introduced a bug in our default scim configuration. What I still do not understand is: Why does the setting /Hotkeys/FrontEnd/Trigger in /etc/scim/config have an influence on skim? OOps, I see that our skim config has the same typo. Checking ...
OK, I fixed that typo in the default configuration of our skim package. Still the following problem remains: If I change the keybinding for the trigger using "scim-setup", this has an immediate effect on skim. This appears strange to me because skim has it's own setup dialog. If I use the setup dialog of skim (started by right-click on the skim icon in the kicker), I cannot influence the keybinding for the trigger key. When I try to change the trigger keys there, the change is ignored. That's strange. Platform is x86_64 (I'm not sure whether that matters).
No, apparently it is not x86_64 specific, Stefan Dirsch can reproduce this on his i386 machine.
I know what's going on in your systems: please use kconfig as the default config module of SCIM, otherwise the skim configure dialog won't be able to change settings specific to libscim
Yes, you are right, when I choose kconfig (and scim-panel-kde if I started skim manually uner FVWM2), it works.
But then I still see the problem that it doesn't work right by default. With /DefaultConfigModule = kconfig /DefaultPanelProgram = /opt/kde3/bin/scim-panel-kde in ~/.scim/global it works fine when skim is used. But there are problems when only scim is used. And vice versa, if /DefaultConfigModule is not "kconfig" and /DefaultPanelProgram is not "/opt/kde3/bin/scim-panel-kde", there are problems with skim. I looked in "scim-setup" for a possibility to change these settings, I cannot find it. Apparently it is not possible to change the /DefaultConfigModule and /DefaultPanelProgram in scim-setup. And why should one need to change this at all? If skim needs "kconfig" and "scim-panel-kde", why doesn't skim enforce the use of "kconfig" and "scim-panel-kde" always? If these settings are the only settings which work, there is no need to offer a configuration option for settings which do not work.
with /DefaultConfigModule = kconfig scim should work fine, what's your observed issues? skim can enfore the use of kconfig, while the setting can also enforce libscim to use the config module
Created attachment 46625 [details] Patch to enforce skim to use kconfig by default. I think we should enforce skim to use kconfig by default, rather than the default config module in /etc/scim/global.
with this patch, if skim is used to start it, everything is fine, but when using scim to start, it won't use kconfig as the config module
Cougar Liu> with /DefaultConfigModule = kconfig Cougar Liu> scim should work fine, what's your observed issues? I tested using a FVWM2 session and used /DefaultConfigModule = kconfig /DefaultPanelProgram = /opt/kde3/bin/scim-panel-kde At the beginning I had only /Hotkeys/FrontEnd/Trigger = Shift+space I activated scim with "Shift+space" and clicked on the setup icon in the panel. Then I added "Control+backslash" as a trigger key. Now I could switch scim *off* using "Control+backslash" but not on. Switching on still worked only with "Shift+space". When I use scim without "kconfig" and scim-panel-kde under FVWM2, there is no such problem, I can add and remove Trigger keys without any problems.
Cougar Liu> with this patch, if skim is used to start it, everything Cougar Liu> is fine, but when using scim to start, it won't use Cougar Liu> kconfig as the config module I think that is good because it avoids the problems I had with kconfig when using scim and not skim.
(In reply to comment #16) > Cougar Liu> with /DefaultConfigModule = kconfig > Cougar Liu> scim should work fine, what's your observed issues? > > I tested using a FVWM2 session and used > > /DefaultConfigModule = kconfig > /DefaultPanelProgram = /opt/kde3/bin/scim-panel-kde > > At the beginning I had only > > /Hotkeys/FrontEnd/Trigger = Shift+space > > I activated scim with "Shift+space" and clicked on the setup icon in > the panel. Then I added "Control+backslash" as a trigger key. Now I > could switch scim *off* using "Control+backslash" but not > on. Switching on still worked only with "Shift+space". I can not reproduce this under KDE I do not think skim should be used under any other desktops than KDE
Cougar Liu> I can not reproduce this under KDE It worked fine for me under KDE as well when using skim (I didn't try with scim only). Cougar Liu> I do not think skim should be used under any other Cougar Liu> desktops than KDE Yes, I think so too. But because of this I wrote that it is a problem to select kconfig manually and write it into the config file: 1) user users KDE and skim. Doesn't work well because kconfig is not used. Therefore the user selects kconfig and scim-panel-kde and it this change gets written in to ~/.scim/global. 2) Now the user logs out of KDE and starts another desktop, for example fvwm2. Because "kconfig" and "scim-panel-kde" are now in ~/.scim/global, they are used, although it is not a KDE desktop. Apparently this causes some problems. Therefore I thought: If "kconfig" and "scim-panel-kde" are necessary for skim to work correctly, then they should be used by default if possible (which is achieved for kconfig by Zhe Su's patch in comment #13). And, as you write above, skim should be used only with KDE, therefore it is not nice if "kconfig" and "scim-panel-kde" are accidentally used under a different desktop only because KDE has been used before. If skim uses them automatically, there is no need to save this setting into the config file and then there is no problem on other desktops. And it is not necessary to be able to select kconfig in the skim setup dialog, if kconfig is the only one which works well and no other options make sense, then it is just an invitation to make mistakes to offer a setup option in the skim setup dialog.
Mike, which client applications did you use for testing in comment #16? If you used a XIM client, that's nothing surprise. Because dynamic event flow is used by default, so the trigger on key is handled by XServer rather than scim x11 frontend. When creating xim server, x11 frontend will register trigger on key into xserver, then it couldn't be changed later. Trigger off key is handled by x11 frontend, so only trigger off action of new trigger key will take effect immediately. Besides this issue, there is another drawback if dynamic event flow is used: Compose keys will not work when scim is deactivated, because all key events won't be sent to scim x11 frontend unless scim is activated. But if we use static event flow, there will be other two issues: 1) The speed will be slow when using xim in remote environment. 2) Some legacy xim applications won't work with scim, such as rxvt and mrxvt. So what's your opinion for this issue? Should we use dynamic event flow by default or not? The corresponding config key is /FrontEnd/X11/Dynamic.
Zhe Su> Mike, which client applications did you use for testing in Zhe Su> comment #16? If you used a XIM client, Yes, I used mlterm as a XIM client (not the built in scim support of mlterm). I understand the behavior now, thank you for the explanation.
So do you think we need to turn off /FrontEnd/X11/Dynamic by default?
Zhe Su> So do you think we need to turn off /FrontEnd/X11/Dynamic by default? I think yes because making Compose keys work by default is quite important and it is difficult to understand that dynamic eventflow can be the reason that they do not work. The speed when using xim in remote environment is probably less important. And rxvt is not important at all in my opinion, it seems to be basically unmaintained for years now. There is practically no traffic on the rxvt-workers mailing list any more for a long time already.
Mike> The speed when using xim in remote environment is probably less Mike> important. Because I think making everything work as foolproof as possible has higher priority than speed.
As suzhe explained, kconfig has nothing to do with misbehavior of trigger keys My point of view is that: no normal user would frequently changes their desktops.
Cougar Liu> My point of view is that: no normal user would frequently changes Cougar Liu> their desktops. I do that all the time, mostly for testing purposes. But probably you are right that most users do not change their desktop often.
[...dynamic event flow ...] Zhe Su> Compose keys will not work when scim is deactivated and when scim is activated they won't work either because then one usually activates an input method like "Anthy" and using compose is again impossible. I tested again with dynamic eventflow and I cannot get compose to work at all with that setting (in applications using XIM). How can I activate scim without choosing an input method? Even if I choose "English/Keyboard" from the input method selection menu, this does not make compose work, the scim-panel disappears and compose doesn't work. Therefore I think we really should use static eventflow by default. Otherwise we will get a lot of bugreports that compose doesn't work. If scim is installed, it is started by default for most languages. It is started for all languages in this list currently: mfabian@magellan:~$ find /etc/X11/xim.d/ -name "*scim*" /etc/X11/xim.d/am/50-scim /etc/X11/xim.d/ja/50-scim /etc/X11/xim.d/ar/50-scim /etc/X11/xim.d/as/50-scim /etc/X11/xim.d/bn/50-scim /etc/X11/xim.d/ko/50-scim /etc/X11/xim.d/cs/50-scim /etc/X11/xim.d/da/50-scim /etc/X11/xim.d/de/50-scim /etc/X11/xim.d/el/50-scim /etc/X11/xim.d/en/50-scim /etc/X11/xim.d/es/50-scim /etc/X11/xim.d/fa/50-scim /etc/X11/xim.d/fi/50-scim /etc/X11/xim.d/fr/50-scim /etc/X11/xim.d/gu/50-scim /etc/X11/xim.d/he/50-scim /etc/X11/xim.d/hi/50-scim /etc/X11/xim.d/hr/50-scim /etc/X11/xim.d/it/50-scim /etc/X11/xim.d/ka/50-scim /etc/X11/xim.d/kk/50-scim /etc/X11/xim.d/kn/50-scim /etc/X11/xim.d/lo/50-scim /etc/X11/xim.d/ml/50-scim /etc/X11/xim.d/my/50-scim /etc/X11/xim.d/nb/50-scim /etc/X11/xim.d/nl/50-scim /etc/X11/xim.d/nn/50-scim /etc/X11/xim.d/pa/50-scim /etc/X11/xim.d/pl/50-scim /etc/X11/xim.d/ru/50-scim /etc/X11/xim.d/sk/50-scim /etc/X11/xim.d/sv/50-scim /etc/X11/xim.d/scim /etc/X11/xim.d/vi/50-scim /etc/X11/xim.d/zh_SG/50-scim /etc/X11/xim.d/zh_CN/50-scim /etc/X11/xim.d/zh_HK/50-scim /etc/X11/xim.d/zh_TW/50-scim mfabian@magellan:~$ It was requested by several users that scim should work after installing without any manual setup. Therefore I made it start for most languages by default if installed (for all languages where there is some input method in scim which supports that language). Even Acer recently requested that scim should work without extra setup after installing the scim packages on an English system. scim is not installed by default when installing in German or English. But users who install it will be very surprised when compose stops working.
Apparently the default for dynamic event flow changed recently. I had /FrontEnd/X11/Dynamic = false in my ~/.scim/config and Stefan Dirsch <sndirsch@suse.de> as well. And we don't remember ever touching this settings. So it looks like we got this copied to our ~/.scim/config when "false" was still the default.
Zhe Su> 2) Some legacy xim applications won't work with scim, such as Zhe Su> rxvt and mrxvt. Mike> And rxvt is not important at all in my opinion And it works with scim even when static eventflow is used. I just tried and couldn't find any problem.
Submitted scim package with the following change to STABLE (should show up in Beta3): ------------------------------------------------------------------- Fri Aug 19 20:14:01 CEST 2005 - mfabian@suse.de - Bugzilla #105319: make /FrontEnd/X11/Dynamic = false the default again to make sure that Compose works always. - Bugzilla #105193: add "Zenkaku_Hankaku" to /Hotkeys/FrontEnd/Trigger (this is the trigger key used MS IME for Japanese). -------------------------------------------------------------------
Looks like there is no problem left in this bugreport → FIXED.
I forgot to submit the last change for skim as well. Done now: ------------------------------------------------------------------- Fri Aug 19 20:57:46 CEST 2005 - mfabian@suse.de - Bugzilla #105319: make /FrontEnd/X11/Dynamic = false the default again to make sure that Compose works always. - Bugzilla #105193: add "Zenkaku_Hankaku" to /Hotkeys/FrontEnd/Trigger (this is the trigger key used MS IME for Japanese). - make "/FrontEnd/SharedInputMethod = true" the default. -------------------------------------------------------------------
Mike, do you incorporate that patch for skim?
The patch from comment #13? Yes, I added that to the SuSE package of skim.