Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput
Hi Mike I don't know whether this is a know issue or not, but Google didn'd find a matching thread: xim: CVS version 1.5 [...] zh_CN*) # Simplified Chinese [...] case $tmplang in zh_CN.UTF-8|zh_CN.utf-8) chinput -gb & ;; *) chinput & ;; esac [...] I have the followig system settings (to combine german and chinese): RC_LANG="de_CH.UTF-8" RC_LC_CTYPE="zh_CN.UTF-8" Problem with chinput: 1) There is no need for an '&', it automatically goes to background 2) Option '-gb' results in: "Basic: Cannot open font "\ "-misc-zysong18030-medium-r-normal-16-000c0iso10646-1" 3) Startup *must* be: LANG=zh_CN LC_ALL=zh_CN chinput Otherwise it does not work! - without "LANG=..." -> Segmentation fault - With "LANG=zh_CN.UTF-8 ..." -> "Can't Open Input Method Service" Any idea? Other experiances? Could you correct it? BTW: Mike Fabian: Do you allow me to publish your xim file on my homepage (will be marc.waeckerlin.org/linux/i18n.php when it's finished)? I see no "License is GPL" comment. Regards Marc
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
I don't know whether this is a know issue or not, but Google didn'd find a matching thread:
xim: CVS version 1.5
[...] zh_CN*) # Simplified Chinese [...] case $tmplang in zh_CN.UTF-8|zh_CN.utf-8) chinput -gb & ;; *) chinput & ;; esac [...]
I have the followig system settings (to combine german and chinese):
RC_LANG="de_CH.UTF-8" RC_LC_CTYPE="zh_CN.UTF-8"
Problem with chinput:
- There is no need for an '&', it automatically goes to background
- Option '-gb' results in: "Basic: Cannot open font "\ "-misc-zysong18030-medium-r-normal-16-000c0iso10646-1"
- Startup *must* be: LANG=zh_CN LC_ALL=zh_CN chinput Otherwise it does not work!
- without "LANG=..." -> Segmentation fault
- With "LANG=zh_CN.UTF-8 ..." -> "Can't Open Input Method Service"
I remember adding the above lines because somebody told me chinput should be started like that. I have never used chinput and there isn't a SuSE package for chinput. I don't plan to create a package either as the intelligent pinyin module of SCIM has become GPL and will be included in SuSE Linux 9.2. So there is really no need for a chinput package anymore. SCIM has become very powerful and can be used to input many languages now. SCIM even has built in support for compose and dead keys, with most other XIM servers you cannot use neither compose nor dead keys. Therefore SCIM will be the default for Japanese, Korean, and Chinese in SuSE Linux 9.2.
Any idea? Other experiances? Could you correct it?
I have changed the part for zh_CN according to your suggestion as follows for SuSE Linux 9.2: zh_CN*) # Simplified Chinese if type -p scim > /dev/null 2>&1 ; then export XMODIFIERS=@im=SCIM export GTK_IM_MODULE=scim export QT_IM_MODULE=scim scim -d elif type -p chinput > /dev/null 2>&1 ; then export XMODIFIERS="@im=Chinput" LANG=zh_CN LC_ALL=zh_CN chinput elif type -p xcin > /dev/null 2>&1 ; then export XMODIFIERS="@im=xcin-zh_CN" LANG=zh_CN LC_ALL=zh_CN xcin & fi ;;
BTW: Mike Fabian: Do you allow me to publish your xim file on my homepage (will be marc.waeckerlin.org/linux/i18n.php when it's finished)?
Yes.
I see no "License is GPL" comment.
I've just added that. You can get the latest version from http://www.suse.de/~mfabian/misc/xim -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
We had this discussion already once some time again. I'd just like stress out the arguments, why I prefer (mini-)chinput over all other know chinese input modules. My test of these modules is some time avo, so perhaps they have become better? Advantages of chinput: - No waste of desktop space: - there is no window, no icon, nothing, as long as I don't enter Chinese - when I enter Chinese, the size of the windows is minimal - It offers intelligent Pin-Yin Problems with chinput: - font size is too small and font is not selectable (afaik) - a lot of character positions are empty (missing in font?) - can't configure ctrl-space to another key combination (afaik) - can't enter Hiragana, Katakana, Hanja The most important point for me is that there is no open window as long as I don't need it, because I use it seldom. - And of course the intelligent Pin Yin. Am Samstag, 4. September 2004 19.21 schrieb Mike FABIAN <Mike FABIAN <mfabian@suse.de>> unter "Re: [m17n] Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput":
I have never used chinput and there isn't a SuSE package for chinput.
There isn't? I have it. Didn't you promise to add it for SuSE 9.1? - Oh, well I see, since I am using apt4rpm, I don't always know where packages come from. The miniChinput package is packed by Thibaut Cousin, so you have to add tcousin to the /etc/apt/sources.list to install it.
I don't plan to create a package either as the intelligent pinyin module of SCIM has become GPL and will be included in SuSE Linux 9.2. So there is really no need for a chinput package anymore.
SCIM has become very powerful and can be used to input many languages now. SCIM even has built in support for compose and dead keys, with most other XIM servers you cannot use neither compose nor dead keys.
I had the problem in KDE that all KDE applications didn't handle ~ or ^ as long as chinput was running. Other applications, such as xemacs had no problem. But this problem is now resolved since KDE 3.3.3.
Therefore SCIM will be the default for Japanese, Korean, and Chinese in SuSE Linux 9.2.
One IM for three languages is surely an advantage, I'll have another look at it, but does it now disappear when it is unused? Regards Marc
Hi, If the first advantage of chinput is the only point you like, then scim is definitly suitable for you. scim is highly configurable, you can let scim don't show anything when it's closed. And you can config the hotkeys by yourself. scim-chinese is a real intelligent pinyin input method just like Microsoft PinYin or ZiGuang Pinyin. It's much better than what's in Chinput. Regards James Su Marc Waeckerlin wrote:
We had this discussion already once some time again. I'd just like stress out the arguments, why I prefer (mini-)chinput over all other know chinese input modules. My test of these modules is some time avo, so perhaps they have become better?
Advantages of chinput:
- No waste of desktop space:
- there is no window, no icon, nothing, as long as I don't enter Chinese
- when I enter Chinese, the size of the windows is minimal
- It offers intelligent Pin-Yin
Problems with chinput:
- font size is too small and font is not selectable (afaik)
- a lot of character positions are empty (missing in font?)
- can't configure ctrl-space to another key combination (afaik)
- can't enter Hiragana, Katakana, Hanja
The most important point for me is that there is no open window as long as I don't need it, because I use it seldom. - And of course the intelligent Pin Yin.
Am Samstag, 4. September 2004 19.21 schrieb Mike FABIAN <Mike FABIAN <mfabian@suse.de>> unter "Re: [m17n] Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput":
I have never used chinput and there isn't a SuSE package for chinput.
There isn't? I have it. Didn't you promise to add it for SuSE 9.1? - Oh, well I see, since I am using apt4rpm, I don't always know where packages come from. The miniChinput package is packed by Thibaut Cousin, so you have to add tcousin to the /etc/apt/sources.list to install it.
I don't plan to create a package either as the intelligent pinyin module of SCIM has become GPL and will be included in SuSE Linux 9.2. So there is really no need for a chinput package anymore.
SCIM has become very powerful and can be used to input many languages now. SCIM even has built in support for compose and dead keys, with most other XIM servers you cannot use neither compose nor dead keys.
I had the problem in KDE that all KDE applications didn't handle ~ or ^ as long as chinput was running. Other applications, such as xemacs had no problem. But this problem is now resolved since KDE 3.3.3.
Therefore SCIM will be the default for Japanese, Korean, and Chinese in SuSE Linux 9.2.
One IM for three languages is surely an advantage, I'll have another look at it, but does it now disappear when it is unused?
Regards Marc
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
the arguments, why I prefer (mini-)chinput over all other know chinese input modules. My test of these modules is some time avo, so perhaps they have become better?
Yes, SCIM has become much better. James Su did really a great job with SCIM.
Advantages of chinput:
- No waste of desktop space:
- there is no window, no icon, nothing, as long as I don't enter Chinese
- when I enter Chinese, the size of the windows is minimal
Same with SCIM
- It offers intelligent Pin-Yin
SCIM offers intelligent Pin-Yin as well. As I don't speak Chinese I cannot judge which one is better, but I trust James Su that the intelligent Pin-Yin in SCIM is better than the one in chinput.
Problems with chinput:
- font size is too small and font is not selectable (afaik)
is selectable in SCIM.
- a lot of character positions are empty (missing in font?)
No such problem in SCIM.
- can't configure ctrl-space to another key combination (afaik)
can be easily configured in SCIM. Even with graphical setup tool.
- can't enter Hiragana, Katakana, Hanja
SCIM can do this and much more.
The most important point for me is that there is no open window as long as I don't need it, because I use it seldom. - And of course the intelligent Pin Yin.
Am Samstag, 4. September 2004 19.21 schrieb Mike FABIAN <Mike FABIAN <mfabian@suse.de>> unter "Re: [m17n] Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput":
I have never used chinput and there isn't a SuSE package for chinput.
There isn't? I have it. Didn't you promise to add it for SuSE 9.1? -
Yes, but this was before the intelligent Pin-Yin of SCIM became open source. After scim-chinese is available with a GPL license (many thanks to James Su), I see no reason to add a chinput package anymore.
Oh, well I see, since I am using apt4rpm, I don't always know where packages come from. The miniChinput package is packed by Thibaut Cousin, so you have to add tcousin to the /etc/apt/sources.list to install it.
I don't plan to create a package either as the intelligent pinyin module of SCIM has become GPL and will be included in SuSE Linux 9.2. So there is really no need for a chinput package anymore.
SCIM has become very powerful and can be used to input many languages now. SCIM even has built in support for compose and dead keys, with most other XIM servers you cannot use neither compose nor dead keys.
I had the problem in KDE that all KDE applications didn't handle ~ or ^ as long as chinput was running. Other applications, such as xemacs had no problem.
I cannot really believe that there was no problem in XEmacs. Probably you used an input method supplied by XEmacs and not dead keys or compose. These don't work together with XIM. It only works with SCIM when using XIM because SCIM implements the compose table of X11 again within SCIM.
But this problem is now resolved since KDE 3.3.3.
Probably only because there is some simple compose support built into Qt.
Therefore SCIM will be the default for Japanese, Korean, and Chinese in SuSE Linux 9.2.
One IM for three languages is surely an advantage,
Not only three languages, SCIM has input methods for many other languages as well. Please have a look!
I'll have another look at it, but does it now disappear when it is unused?
-- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Am Montag, 6. September 2004 12.21 schrieb Mike FABIAN <Mike FABIAN <mfabian@suse.de>> unter "Re: [m17n] chinput vs. scim [Re: Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput]":
Yes, SCIM has become much better. James Su did really a great job with SCIM.
Yes, you are right, SCIM is really much better now, so SCIM is the winner. The only advantage of Chinput is, that it's much simpler if you only want to enter chinese. BTW: There's not really need for a Russian, Arabian, Greek, Tamil, Kannada or whatsoever "alfabetical" language (in contrary to the asian "sign" languages), because you can simply switch the keyboard in KDE to any of the given layouts and then enter characters of that language. Ok, but this "unfortunately" outdates my webpage, where I intended to explain, how the different input servers can be mixed. But if one can everything... Some problems with SCIM are left: - **** BUG **** .xim (not the newest, of SuSE 9.1) starts scim -d. This does not work in KDE, it must be skim -d, otherwise konsole terminals tend to crash and the icon in the launchpad flickers (appears, disappears, appears, disappears, ...). -> **** SEVERE BUG **** Oh no! Just now, I started "kdesu synaptic" and pressed "ctrl-f" for "find" and clicked on the selection button, just now the icon in the panel started flickering, even with skim, and the whole X11 hangs, no chance! Ok, ctrl-alt-F2 works, so I can kill synaptics, but this seems still to be a severe bug in SCIM! But it is not the icon of skim that flickers, but the one of the scim (isn't that a gnome/gtk panel icon?!? why does it appear when I do something in synaptic? because synaptic is a gnome application?) -> well, that's a blocker! New experience: It depends in which situation the flickering starts, so it either blocks the whole X11, or (as just now) only synaptic. This behaviour is reproducible. Strange, even after killing all scim and skim processes the icon in the taskbar remains for several seconds, but now doesn't flicker anymore. Oh, I understand, there are not only scim/skim processes from the user, but also scim-launcher and two scim-panel-gtk running under root!!!! Why?!? How to disable?!? Oh, after killing the two scim-panel-gtk processes always restart! That's annoying! Especially because I don't want gtk but the KDE integration! Strange, now "su - USER" hangs in the text mode, while "su -" as USER still works! Even more strange, a brute and cruell "cd /usr/lib/scim-1.0; rm scim-panel-gtk scim-launcher" followed by a kill of the running processes still does not help the synaptic program, it hangs, except that the scim icon does not flicker any more. After "rpm -e" for all scim packages, synaptic works again. - If I install scim-m17n, scim fails to start! I installed: scim-1.0.0-0.1 scim-hangul-0.1.2-0.1 skim-0.9.7-1.1 scim-chinese-0.4.2-1.tcousin scim-tables-ja-0.4.3-1.tcousin scim-tables-ko-0.4.3-1.tcousin scim-tables-zh-0.4.3-1.tcousin scim-tables-additional-0.4.3-1.tcousin Not installed: scim-config-gconf scim-config-socket scim-frontend-socket scim-gtk2-immodule scim-server-socket scim-devel scim-m17n scim-uim KDE is in release 3.3.0-8
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
BTW: There's not really need for a Russian, Arabian, Greek, Tamil, Kannada or whatsoever "alfabetical" language (in contrary to the asian "sign" languages), because you can simply switch the keyboard in KDE to any of the given layouts and then enter characters of that language.
I have not yet tried Russian, Arabian, Greek, Tamil, and Kannada, but I think there are reasons why one might want such input methods, even if there are keyboard layouts. For example, SCIM also supports a M17N-t-latin-post input method which can be used to input European languages. For example German: a" -> ä s/ -> ß ... As I use US keyboard layout, I like that very much. Of course I could switch to German keyboard layout to input German characters, but then many characters are on different keys. Switching between different keyboard layouts reduces my typing speed a lot. Imagine for example that you usually use German but also type French, and Spanish from time to time. Switching between German, French and Spanish keyboard layouts will be very inefficient, the differences in layout are bit and you cannot easily adapt, especially when touch typing (not looking at the keyboard at all). In my opinion, one can type much faster if one stays with one keyboard layout and learn to use that really efficiently. But then one has to use input methods for everything not available on that keyboard layout of course. Therefore I like input methods like M17N-t-latin-post and maybe there are similar reasons why one might want to use input methods for other alphabetic languages exist. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Am Dienstag, 7. September 2004 11.37 schrieb Mike FABIAN <Mike FABIAN <mfabian@suse.de>> unter "[m17n] input methods for alphabetical languages (was: [m17n] And the winner is... (or not?) SCIM is better, but buggy)":
Imagine for example that you usually use German but also type French, and Spanish from time to time. Switching between German, French and Spanish keyboard layouts will be very inefficient, the
That's why we have Swiss German keyboards with èéàç with shift+üöä4. For the big umlauts and other accents, we need dead keys (or "Compose" on Sun), but that does not matter, because they are relatively seldom.
In my opinion, one can type much faster if one stays with one keyboard layout and learn to use that really efficiently. But then one has to use input methods for everything not available on that keyboard layout of course.
Yes, that's a point of view. My problem is, that most key layouts expect z where y resides and vice versa. Regards Marc
Hi, The issues that you met are not bugs of SCIM. The reason is that you are using a wrong scim binary package. Because scim depends on gtk2 version. scim binary compiled against gtk2+2.2.x can not work with gtk2+2.4.x. So you must install the right binary package, or build and install scim from source. Regards James Su Marc Waeckerlin wrote:
Am Montag, 6. September 2004 12.21 schrieb Mike FABIAN <Mike FABIAN <mfabian@suse.de>> unter "Re: [m17n] chinput vs. scim [Re: Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput]":
Yes, SCIM has become much better. James Su did really a great job with SCIM.
Yes, you are right, SCIM is really much better now, so SCIM is the winner. The only advantage of Chinput is, that it's much simpler if you only want to enter chinese.
BTW: There's not really need for a Russian, Arabian, Greek, Tamil, Kannada or whatsoever "alfabetical" language (in contrary to the asian "sign" languages), because you can simply switch the keyboard in KDE to any of the given layouts and then enter characters of that language.
Ok, but this "unfortunately" outdates my webpage, where I intended to explain, how the different input servers can be mixed. But if one can everything...
Some problems with SCIM are left:
- **** BUG **** .xim (not the newest, of SuSE 9.1) starts scim -d. This does not work in KDE, it must be skim -d, otherwise konsole terminals tend to crash and the icon in the launchpad flickers (appears, disappears, appears, disappears, ...).
-> **** SEVERE BUG **** Oh no! Just now, I started "kdesu synaptic" and pressed "ctrl-f" for "find" and clicked on the selection button, just now the icon in the panel started flickering, even with skim, and the whole X11 hangs, no chance! Ok, ctrl-alt-F2 works, so I can kill synaptics, but this seems still to be a severe bug in SCIM! But it is not the icon of skim that flickers, but the one of the scim (isn't that a gnome/gtk panel icon?!? why does it appear when I do something in synaptic? because synaptic is a gnome application?) -> well, that's a blocker! New experience: It depends in which situation the flickering starts, so it either blocks the whole X11, or (as just now) only synaptic. This behaviour is reproducible. Strange, even after killing all scim and skim processes the icon in the taskbar remains for several seconds, but now doesn't flicker anymore. Oh, I understand, there are not only scim/skim processes from the user, but also scim-launcher and two scim-panel-gtk running under root!!!! Why?!? How to disable?!? Oh, after killing the two scim-panel-gtk processes always restart! That's annoying! Especially because I don't want gtk but the KDE integration! Strange, now "su
USER" hangs in the text mode, while "su -" as USER still works! Even more strange, a brute and cruell "cd /usr/lib/scim-1.0; rm scim-panel-gtk scim-launcher" followed by a kill of the running processes still does not help the synaptic program, it hangs, except that the scim icon does not flicker any more. After "rpm -e" for all scim packages, synaptic works again.
If I install scim-m17n, scim fails to start!
I installed: scim-1.0.0-0.1 scim-hangul-0.1.2-0.1 skim-0.9.7-1.1 scim-chinese-0.4.2-1.tcousin scim-tables-ja-0.4.3-1.tcousin scim-tables-ko-0.4.3-1.tcousin scim-tables-zh-0.4.3-1.tcousin scim-tables-additional-0.4.3-1.tcousin
Not installed: scim-config-gconf scim-config-socket scim-frontend-socket scim-gtk2-immodule scim-server-socket scim-devel scim-m17n scim-uim
KDE is in release 3.3.0-8
Am Dienstag, 7. September 2004 15.01 schrieb James Su <James Su <suzhe@tsinghua.org.cn>> unter "Re: [m17n] And the winner is... (or not?) SCIM is better, but buggy [Re: chinput vs. scim [Re: Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput]]":
The issues that you met are not bugs of SCIM. The reason is that you are using a wrong scim binary package. Because scim depends on gtk2 version. scim binary compiled against gtk2+2.2.x can not work with gtk2+2.4.x. So you must install the right binary package, or build and install scim from source.
So you mean the dependencies in the RMS of the apt4rpm repositories are not correct? Then I should complain against the RPM builders. Or probably the spec file is wrong, who provides the spec file? rpm -qip scim_1.0.0-0.1_i586.rpm --> Packager is SuSE Built on host gray.suse.de -> is this built by you, Mike? rpm -qRp scim_1.0.0-0.1_i586.rpm | grep gtk --> libgtk-x11-2.0.so.0 libscim-gtkutils-1.0.so.0 Is this correct? No dependency to gtk2-2.x.y? I have installed gtk-2.4.9-0.gbv.1 Regards Marc
Hi, This package should be compiled against gtk2-2.2.x for SL9.1, so it can not work with gtk2-2.4.x. Regards James Su Marc Waeckerlin wrote:
Am Dienstag, 7. September 2004 15.01 schrieb James Su <James Su <suzhe@tsinghua.org.cn>> unter "Re: [m17n] And the winner is... (or not?) SCIM is better, but buggy [Re: chinput vs. scim [Re: Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput]]":
The issues that you met are not bugs of SCIM. The reason is that you are using a wrong scim binary package. Because scim depends on gtk2 version. scim binary compiled against gtk2+2.2.x can not work with gtk2+2.4.x. So you must install the right binary package, or build and install scim from source.
So you mean the dependencies in the RMS of the apt4rpm repositories are not correct? Then I should complain against the RPM builders. Or probably the spec file is wrong, who provides the spec file?
rpm -qip scim_1.0.0-0.1_i586.rpm --> Packager is SuSE Built on host gray.suse.de -> is this built by you, Mike?
rpm -qRp scim_1.0.0-0.1_i586.rpm | grep gtk --> libgtk-x11-2.0.so.0 libscim-gtkutils-1.0.so.0
Is this correct? No dependency to gtk2-2.x.y?
I have installed gtk-2.4.9-0.gbv.1
Regards Marc
Am Dienstag, 7. September 2004 15.36 schrieb James Su <James Su <suzhe@tsinghua.org.cn>> unter "Re: [m17n] And the winner is... (or not?) SCIM is better, but buggy [Re: chinput vs. scim [Re: Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput]]":
This package should be compiled against gtk2-2.2.x for SL9.1, so it can not work with gtk2-2.4.x.
Then this dependency should be part of the spec file! Who is the author of the RPM spec file, James or Mike? Could you please update the dependencies? Is it possible to compile scim with gtk2-2.4.x?
Marc Waeckerlin wrote:
I have installed gtk-2.4.9-0.gbv.1
Regards Marc
James Su <suzhe@tsinghua.org.cn> さんは書きました:
This package should be compiled against gtk2-2.2.x for SL9.1, so it can not work with gtk2-2.4.x.
Regards James Su
Marc Waeckerlin wrote:
[...]
So you mean the dependencies in the RMS of the apt4rpm repositories are not correct? Then I should complain against the RPM builders. Or probably the spec file is wrong, who provides the spec file?
rpm -qip scim_1.0.0-0.1_i586.rpm --> Packager is SuSE Built on host gray.suse.de -> is this built by you, Mike?
Yes. But I built it for SuSE 9.1/SLES9. I.e. this package is compiled against *exactly* the libraries as they were on SuSE Linux 9.1. For gtk2 this means gtk2-2.2.4-121.i586.rpm was used.
rpm -qRp scim_1.0.0-0.1_i586.rpm | grep gtk --> libgtk-x11-2.0.so.0 libscim-gtkutils-1.0.so.0
Is this correct? No dependency to gtk2-2.x.y?
I have installed gtk-2.4.9-0.gbv.1
-- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Am Dienstag, 7. September 2004 16.00 schrieb Mike FABIAN <Mike FABIAN <mfabian@suse.de>> unter "Re: [m17n] And the winner is... (or not?) SCIM is better, but buggy [Re: chinput vs. scim [Re: Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput]]":
But I built it for SuSE 9.1/SLES9. I.e. this package is compiled against *exactly* the libraries as they were on SuSE Linux 9.1. For gtk2 this means gtk2-2.2.4-121.i586.rpm was used.
Could you update the spec file so, that the dependency to the gtk2 is reflected in the rpm? Otherwise apt4rpm (or also YOU) install new releases of gtk2 without being able to detect that a dependency was broken. Obviously this dependency is a killer, so it should definitely be noted in the spec file. Regards Marc
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
Am Dienstag, 7. September 2004 16.00 schrieb Mike FABIAN <Mike FABIAN <mfabian@suse.de>> unter "Re: [m17n] And the winner is... (or not?) SCIM is better, but buggy [Re: chinput vs. scim [Re: Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput]]":
But I built it for SuSE 9.1/SLES9. I.e. this package is compiled against *exactly* the libraries as they were on SuSE Linux 9.1. For gtk2 this means gtk2-2.2.4-121.i586.rpm was used.
Could you update the spec file so, that the dependency to the gtk2 is reflected in the rpm? Otherwise apt4rpm (or also YOU) install new releases of gtk2 without being able to detect that a dependency was broken. Obviously this dependency is a killer, so it should definitely be noted in the spec file.
Yes, but this is somewhat difficult. I use the same scim.spec file for different versions of SuSE Linux. Usually the automatic dependencies created by Autoreqprov: on should be enough. The dependency you see with mfabian@magellan:~$ rpm -qR scim | grep gtk libgtk-x11-2.0.so.0()(64bit) libscim-gtkutils-1.0.so.0()(64bit) mfabian@magellan:~$ is created automatically. I believe it is a bug in GTK2 if gtk-2.2.x and gtk-2.4.x are incompatible but the version number of the library libgtk-x11 is the same. Now the question is what would be a good workaround. I could add a hack to insert a Requires: gtk2-<exact-version-number-used-when-building> into the scim.spec file automatically when building. But that has the problem that we would get something like Requires: gtk2 = 2.2.4 for example and then the tools like apt4rpm and YOU would complain that that a dependency was broken if there is a minor version upgrade to gtk2 for example to gtk2-2.2.5. And this complaint would be useless and only disturbing. A Requires: gtk2 >= 2.2.4 obviously would not solve the problem either. I really think this is a problem created by GTK2 because they didn't correctly bump the version of their library. Maybe I build another set of scim and related packages for SuSE Linux 9.1-i386+kde (that SuSE Linux 9.1 plus the updates from ftp://ftp.suse.com/pub/suse/i386/supplementary/ which include gtk2-2.4.x, therefore such packages should work for you. But I cannot tell now when I will find time for that. Note that the packages from that supplementary directory are always to be regarded as somewhat experimental and risky. Read ftp://ftp.suse.com/pub/suse/i386/supplementary/README.txt for details. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Am Dienstag, 7. September 2004 19.22 schrieb Mike FABIAN <Mike FABIAN <mfabian@suse.de>> unter "Re: [m17n] And the winner is... (or not?) SCIM is better, but buggy [Re: chinput vs. scim [Re: Problem with .xim on SuSE 9.1, Chinese zh_CN.UTF-8, miniChinput]]":
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
Could you update the spec file so, that the dependency to the gtk2 is reflected in the rpm? Otherwise apt4rpm (or also YOU) install new releases of gtk2 without being able to detect that a dependency was broken. Obviously this dependency is a killer, so it should definitely be noted in the spec file.
Yes, but this is somewhat difficult. I use the same scim.spec file for different versions of SuSE Linux. Usually the automatic dependencies created by
Autoreqprov: onshould be enough. The dependency you see with
mfabian@magellan:~$ rpm -qR scim | grep gtk libgtk-x11-2.0.so.0()(64bit) libscim-gtkutils-1.0.so.0()(64bit) mfabian@magellan:~$is created automatically. I believe it is a bug in GTK2 if gtk-2.2.x and gtk-2.4.x are incompatible but the version number of the library libgtk-x11 is the same.
Yes, perhaps. It is quite strange that this kind of incompatibility is not detected by rpm. Is this really the reason, why scim does not work?
Now the question is what would be a good workaround. I could add a hack to insert a Requires: gtk2 = 2.2.4
I don't know RPM too deep. Is it possible to write two requirements: Requires: gtk2 >= 2.2.0 Requires: gtk2 < 2.4.0 or: Requires: 2.2.0 <= gtk2 < 2.4.0
obviously would not solve the problem either. I really think this is a problem created by GTK2 because they didn't correctly bump the version of their library.
I agree.
Maybe I build another set of scim and related packages for SuSE Linux 9.1-i386+kde (that SuSE Linux 9.1 plus the updates from ftp://ftp.suse.com/pub/suse/i386/supplementary/ which include gtk2-2.4.x, therefore such packages should work for you.
That's a possibility. In my opinion, the best solution is to provide three packages: scim scim-gtk (or scim-gnome) scim-qt (or scim-kde) where scim contains no gtk at all. Why should my scim be linked to gtk, if I don't need it, because e.g. I use KDE (or twm or whatsoever)?
But I cannot tell now when I will find time for that.
Send a message to this list when you are finished. Thanks Regards Marc
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
Am Dienstag, 7. September 2004 19.22 schrieb Mike FABIAN <Mike FABIAN
Usually the automatic dependencies created by
Autoreqprov: onshould be enough. The dependency you see with
mfabian@magellan:~$ rpm -qR scim | grep gtk libgtk-x11-2.0.so.0()(64bit) libscim-gtkutils-1.0.so.0()(64bit) mfabian@magellan:~$is created automatically. I believe it is a bug in GTK2 if gtk-2.2.x and gtk-2.4.x are incompatible but the version number of the library libgtk-x11 is the same.
Yes, perhaps. It is quite strange that this kind of incompatibility is not detected by rpm.
This cannot be detected by rpm if the version number of the library is the same.
Is this really the reason, why scim does not work?
Yes.
Now the question is what would be a good workaround. I could add a hack to insert a Requires: gtk2 = 2.2.4
I don't know RPM too deep. Is it possible to write two requirements:
Requires: gtk2 >= 2.2.0 Requires: gtk2 < 2.4.0
or:
Requires: 2.2.0 <= gtk2 < 2.4.0
Yes, something like this is possible the following works Requires: gtk2 >= 2.2.0, gtk2 < 2.4.0 and your first suggestion also works. But this quite ugly as well because this range has to be edited manually. It would be much better if the automatic dependencies were already correct. If such a hack is needed, something went already wrong. I have uploaded scim packages with that dependency to ftp://ftp.suse.com/pub/projects/m17n/9.1 now.
Maybe I build another set of scim and related packages for SuSE Linux 9.1-i386+kde (that SuSE Linux 9.1 plus the updates from ftp://ftp.suse.com/pub/suse/i386/supplementary/ which include gtk2-2.4.x, therefore such packages should work for you.
That's a possibility.
In my opinion, the best solution is to provide three packages: scim scim-gtk (or scim-gnome) scim-qt (or scim-kde)
where scim contains no gtk at all. Why should my scim be linked to gtk, if I don't need it, because e.g. I use KDE
You can of course use the gtk frontend of SCIM even when using KDE and this will be the default for SuSE 9.2 because the gtk gui of SCIM is currently more reliable.
(or twm or whatsoever)?
You need some graphical frontend for SCIM even if you use twm or another simple windowmanager (I use fvwm by the way). So you need either the gtk or the qt gui for SCIM. There is no qt support in the scim packages, this is already in a separate package "skim". It might make sense to split the gtk support out of the main SCIM package.
But I cannot tell now when I will find time for that.
Send a message to this list when you are finished.
Of course. But I'm not sure whether I will be able to do it. Don't hold your breath. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Mike,
where scim contains no gtk at all. Why should my scim be linked to gtk, if I don't need it, because e.g. I use KDE
You can of course use the gtk frontend of SCIM even when using KDE and this will be the default for SuSE 9.2 because the gtk gui of SCIM is currently more reliable.
On Monday I upgraded to the latest scim rpms from the suse ftp server and thought that I would give skim a whirl for the first time. Now I'm not sure if it is the latest scim or skim that has made the difference but lots of little annoyances have disappeared. With previous versions of scim and the gtk panel I could never get the entry box to appear where I was typing (this is under KDE). In OpenOffice.org if I entered some text and then went to the middle of the text and entered more characters there would be a horrible mess with the cursor jumping to the end of the row and possibly leaving the characters sprayed over the existing text. For the first time under Linux I now feel that I can use chinese IM and not feel that I am using something inferior than the windows IM. Well done James Su and any contributors. So although the gtk gui will be the default will skim be included for the more adventurous users? Finally in the big betting game for the release date of SuSE9.2 will you risk the wrath of management and hazard a 'guess' at a release date? Jethro Cramp ------------------ jsc @ rock-tnsc.com
Jethro Cramp <jsc@rock-tnsc.com> さんは書きました:
So although the gtk gui will be the default will skim be included for the more adventurous users?
Yes.
Finally in the big betting game for the release date of SuSE9.2 will you risk the wrath of management and hazard a 'guess' at a release date?
Usually SuSE Linux is released about every six months. When was the last release? April? So the next release is probably around six months later. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
Maybe I build another set of scim and related packages for SuSE Linux 9.1-i386+kde (that SuSE Linux 9.1 plus the updates from ftp://ftp.suse.com/pub/suse/i386/supplementary/ which include gtk2-2.4.x, therefore such packages should work for you.
That's a possibility.
[...]
But I cannot tell now when I will find time for that.
Send a message to this list when you are finished.
I was to busy to fix the build problems of the scim packages on 9.1-i386+kde. But Zhe Su, the SCIM author, has fixed the GTK2 binary compatibility issue in the meantime. scim 1.0.1 build against gtk2-2.2.x should now work when used together with gtk2-2.4.x. scim-1.0.1 packages and related packages (like scim-chinese, scim-hangul, ... build against scim-1.0.1) are now available here: ftp://ftp.suse.com/pub/projects/m17n/9.1/ Please try these, they should work on your system with gtk2-2.4.x. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Am Dienstag, 21. September 2004 15.05 schrieb Mike FABIAN <Mike FABIAN <mfabian@suse.de>> unter "[m17n] SCIM: GTK2 binary compatibility issue fixed (was: [m17n] SCIM Packages and GTK+)":
But Zhe Su, the SCIM author, has fixed the GTK2 binary compatibility issue in the meantime. scim 1.0.1 build against gtk2-2.2.x should now work when used together with gtk2-2.4.x.
Thank you, it seems to work with synaptic now. The only problem, I have now is, it doesn't work in XEmacs any more. If I enter e.g. Chinese, then I don't get the signs, but something like: ä,-°a\233½ Writing in another window then copy pasting to XEmacs works. Also the buffer is in utf8, I checked this. Any idea? Regards Marc
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
The only problem, I have now is, it doesn't work in XEmacs any more. If I enter e.g. Chinese, then I don't get the signs, but something like: ä,-°a\233½
Writing in another window then copy pasting to XEmacs works. Also the buffer is in utf8, I checked this.
That has nothing to do with SCIM, only with XEmacs. It works for me, this is an XEmacs setup problem. Are you using the SuSE rpm for XEmacs or did you compile XEmacs yourself? -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Mike FABIAN <mfabian@suse.de> さんは書きました:
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
The only problem, I have now is, it doesn't work in XEmacs any more. If I enter e.g. Chinese, then I don't get the signs, but something like: ä,-°a\233½
Writing in another window then copy pasting to XEmacs works. Also the buffer is in utf8, I checked this.
That has nothing to do with SCIM, only with XEmacs.
It works for me, this is an XEmacs setup problem.
My personal XEmacs setup is apparently a bit better in that respect than the current default SuSE XEmacs setup ...
Are you using the SuSE rpm for XEmacs or did you compile XEmacs yourself?
Please try the updated XEmacs packages below, I fixed the default setup of XEmacs a little bit to make this work by default. ftp://ftp.suse.com/pub/projects/m17n/9.1/9.1-i386/xemacs-21.4.15-59.2.i586.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/9.1-i386/xemacs-el-21.4.15-59.2.i586.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/9.1-i386/xemacs-info-21.4.15-59.2.i586.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/9.1-x86_64/xemacs-21.4.15-59.2.x86_64.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/9.1-x86_64/xemacs-el-21.4.15-59.2.x86_64.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/9.1-x86_64/xemacs-info-21.4.15-59.2.x86_64.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/i586/xemacs-21.4.15-59.2.i586.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/i586/xemacs-el-21.4.15-59.2.i586.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/i586/xemacs-info-21.4.15-59.2.i586.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/src/xemacs-21.4.15-59.2.src.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/x86_64/xemacs-21.4.15-59.2.x86_64.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/x86_64/xemacs-el-21.4.15-59.2.x86_64.rpm ftp://ftp.suse.com/pub/projects/m17n/9.1/x86_64/xemacs-info-21.4.15-59.2.x86_64.rpm -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
Some problems with SCIM are left:
- **** BUG **** .xim (not the newest, of SuSE 9.1) starts scim -d. This does not work in KDE, it must be skim -d, otherwise konsole terminals tend to crash and the icon in the launchpad flickers (appears, disappears, appears, disappears, ...).
-> **** SEVERE BUG **** Oh no! Just now, I started "kdesu synaptic" and
I cannot reproduce these problems, neither on SuSE Linux 9.1 nor on SLES9 (which is based on SuSE Linux 9.1). This means gtk2-2.2.4 and KDE 3.2.1. Did you update gtk2 packages as James suspected in his reply? -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
- **** BUG **** .xim (not the newest, of SuSE 9.1)
the newest file is here http://www.suse.de/~mfabian/misc/xim
starts scim -d. This does not work in KDE, it must be skim -d,
No, "scim -d" should work just fine (and it work for me). If you want to use skim by default, see http://freedesktop.org/~cougar/skim/doc/user/en/#start-skim -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
participants (4)
-
James Su -
Jethro Cramp -
Marc Waeckerlin -
Mike FABIAN