Bug 112631
Summary: | kinput2 parameters for using FreeWnn are incorrect | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Eido Inoue <havill> | ||||||
Component: | xinitrc | Assignee: | Mike A. Harris <mharris> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 1 | CC: | eng-i18n-bugs, petersen | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 3.36 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2004-03-16 15:22:10 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Eido Inoue
2003-12-25 06:30:29 UTC
Created attachment 96695 [details]
correctly senses whether Canna or FreeWnn is available
The patch also forces kinput2 to use the modern XIM protocol, which is more
consistent with all of our other CJK languages (vs the Japanese only and
not-part-of-X kinput protocol).
typo in the steps-to-reproduce: typing "nihongo" into kinput2 produces FOUR, not three, Japanese hiragana characters: "ã«ã»ãã". The four characters should convert into three han ideographs: "æ¥æ¬èª". also, the patch, when given a choice between FreeWnn and Canna server (both are running), will prefer Wnn (aka jserver in the ps list). This behavior is changed from before, where it would pick the cannaserver if both were running. I changed this because Canna sucks compared to Wnn. ;) Even if you hate Canna's convertion behavior, I disagree your changes, because the upstream continues to maintains Canna again (by another people on sourceforge.jp) and there are a possibility that behavior is fixed in the future. but FreeWnn isn't maintained for a long time and FreeWnn is also not enough to input Japanese. it's just little better than FC1's Canna. I would respect the upstream's activity. My apologies for disrespecting the Canna team. I meant to say that FreeWnn currently does not suffer from the bug 112760 , bug 112762 , or bug 112763 , among other things, and may present a more friendlier, easier to use environment for the non-power/non-hobbyist desktop user. The patch submitted can trivially be changed to prefer Canna over FreeWnn should both be running. However, this bug is still valid in that the current conversion chooser code in xinput is incorrect; FreeWnn will NEVER be chosen, because the choser code incorrectly uses ldd to determine if cannaserver, aka irohaserver, is running. Also, I stand by my assertion that running two conversion servers is not necessary. As part of our desktop reform program, we have chosen one application to be the "supported" application in most cases (i.e. Mozilla for browsing, Evolution for mail (if someone wants Mozilla for mail, they can still get it by going to Main Menu->Internet->Other Internet Applications) I'm not saying that either Canna or FreeWnn should be removed from the distribution. I'm just saying that only one should be running by default. kinput2 can only use one at a time, after all. To have a server running and not being used (currently jserver) not only waste resources, it unnecessarily increases ones security risk (both Canna and FreeWnn have had a history of security related problems). Created attachment 96733 [details]
revised patch which mimics current distro behavior
The only difference between the previous patch is the priority order. If both
Canna (cannaserver/irohaserver) and FreeWnn server (jserver) are running,
kinput connected to Canna, which mimics current behavior.
Ok, btw I was actually planning to turn off jserver for FC2. Included your patch in update of xinput I'm preparing locally for iiimf support. A question about comment 1, is the "+kinput -xim" really necessary, doesn't kinput2 uses XIM by default anyway? Only kterm supports the kinput protocol, and kterm works well with xim protocol... comment 8: the parameters may be pedantic (I'm not sure), but they don't hurt. Like Nakai implied, there's no reason to use the kinput/kinput2 protocol anymore, even for kterm Fixed in xinitrc 3.36 Adrian, btw with selinux in enforcing mode, "service [server] status" no longer works for non-privileged users... any idea for alternatives? (For Canna there exists cannaping.) I'm new to SELinux. Lemme get a grasp on it and figure out what you can and can't do. My first thought is to get the pid from /var/run and use ps to check to see if it's alive. The second alternative would be to connect a socket to the wnn port to see if it's listening. Why not read the initscript and see how it checks status, then try to do the same thing. It's probably checking /var/lock/subsys/<foo> and getting the PID then checking for that PID running with kill -0 or something? comment 14: I could, but 1) the point of using the /sbin/service command was to abstract the interface should the details change, and 2) I assume that if /sbin/service can't be executed, then neither can the files/pids that the service script touches internally. The cleanest way I can think of that survives upgradability is to send a NOP to it's listening port. Yeah, I agree.. the initscript code could change anytime, making the method no longer work. Abstraction or another method does sound better. The service status problem with enforcing selinux is bug 119408 btw. Anyway we'd like to separate all the individual IM configuration stuff out of xinput into separate shell config files belonging to the inidividual IMs, which xinput will source depending on the locale - which will simply future xinput maintenance significantly - so then this will no longer be a xinitrc issue fwiw. That sounds like a fantastic idea Jens. If you'd like to discuss this sometime let me know and we can work out together what is best. Thanks for the suggestion. Mike, I'm glad to hear you feel that way. :) Sure, I'd be happy to discuss in bugzilla and/or irc some time. (I opened bug 119785 for this since it doesn't really belong here.) |