Bug 119785
| Summary: | all IM configuration code should be separated out of xinput | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jens Petersen <petersen> |
| Component: | xinitrc | Assignee: | Mike A. Harris <mharris> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 2 | CC: | djoo, eng-i18n-bugs, havill, hp, kem, llch, notting, otaylor, yshao |
| Target Milestone: | --- | Keywords: | FutureFeature, i18n |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-06-29 18:04:32 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 119404, 125997 | ||
| Attachments: | |||
I think this is a wonderful idea Jens, and I like the design overview as well. I would not put it in /usr/share I don't think though. It should probably be in /etc/X11/xinit or somewhere else under /etc/X11 no? I think it'd be good to get some feedback from others as well, to hone the design and hear other ideas too, so I've added a few people to CC for comment. It'd be nice to have this for FC2 I think. Just after hitting submit, I thought that it might be a good idea to bounce this idea of fedora-devel-list to see if any volunteers have additional modularization suggestions, etc. Another benefit of this design, is that a bug in xinput script right now can potentially kill all IM users. While that's still true for the above design, it is much less of a chance because a lot of the code gets factored out, reducing risk. As we know, we've both recently broken xinitrc files in interesting ways recently, so this would help mitigate our rampant carelessness in the future. ;o) I know I kicked myself a few times for some of those dumb bugs I goofed up. ;o) Thanks again, TTYL Mike, yep you're right we don't need "/usr/share/xinput.d/": "/etc/X11/xinit/xinput.d/" should have symlinks like: /etc/X11/xinit/xinput.d/hi_IN -> /etc/alternatives/xinput-hi_IN /etc/X11/xinit/xinput.d/ja_JP -> /etc/alternatives/xinput-ja_JP /etc/X11/xinit/xinput.d/ko_KO -> /etc/alternatives/xinput-ko_KO /etc/X11/xinit/xinput.d/zh_CN -> /etc/alternatives/xinput-zh_CN /etc/X11/xinit/xinput.d/zh_TW -> /etc/alternatives/xinput-zh_TW and then for example /etc/alternatives/xinput-hi_IN -> /etc/X11/xinit/xinput.d/htt /etc/alternatives/xinput-ja_JP -> /etc/X11/xinit/xinput.d/kinput2-canna /etc/alternatives/xinput-ko_KO -> /etc/X11/xinit/xinput.d/nabi /etc/alternatives/xinput-zh_CN -> /etc/X11/xinit/xinput.d/htt /etc/alternatives/xinput-zh_TW -> /etc/X11/xinit/xinput.d/htt Jens: Ok, sounds reasonable to me. How about posting this idea to fedora-devel-list for community feedback? Also, I'm not sure wether we should do this for FC2, or wait for FC3 now, as time is tight, and there's lots of work yet to do. What do you think? Thanks in advance, TTYL You're probably right actually: I agree it is late to be doing this now, so let's defer it to FC3. Created attachment 99182 [details]
current xinput.d/ patch
Here's my xinput.d patch in its current form for the record.
Created attachment 99183 [details]
xinitrc with xinput.d support
and the xinput file itself, which is shorter than the above patch...
Created attachment 99184 [details]
current xinitrc xinput.d/ patch (untested)
for the record here is my current patch for implementating xinput.d/ support.
Created attachment 99273 [details]
tested and working implementation of xinput.d/
Created attachment 99274 [details]
latest working xinput file (shorter than patch)
Mike, since Test3 is delayed for a week, I think it would be good to get this into FC2 after all. What do you think? Actually I forgot to mention that xinput needs fixing anyway because of "service <server> status" no longer working under selinux for normal users. Shortly after test2 I realised that the current version of xinput using "service IIim status" was just a temporary fix to the problems in test2 because of service status with selinux not working - and it was thinking of how to best fix that that led to the idea of input.d/ support. It really would be the simplest way to fix xinput now, IMHO. It occurred to me that since most non-Asian users do not need to use any Input Methods (IMs) at all when running X, there is no need for them all to run xinput (xinput.sh) every time they start an X session since it is just a no-op for them. Therefore it would make more sense to move xinput out into a separate package that IM packages would require. This package could also im-switch and a future GUI IM confiuration problem. This would lead to less bug reports on xinitrc from people who don't actually need xinput.sh. And since the I18N Team can maintain the new package, it will ease the current problem of having to overcome the hurdle everytime of getting xinput updated in xinitrc, and reduce the maintainence burden on the xinitrc maintainer. Created attachment 101334 [details]
newer tested xinput.sh with a few more improvements
Mike, here is an update of xinput.sh with xinput.d/ support for FC3.
I still think separating out xinput.sh into a separate package is a good
idea though and with the latest xinitrc only sourcing xinitrc.d/*.sh have had
the
chance to test running without xinput and I haven't seen any problems yet
(when one doesn't want to use an IM).
Created attachment 101352 [details]
patch to update xinitrc/xinput for xinput.d/
Above is an updated patch to add the new xinput to xinitrc.
Patch included necessary changes to spec file (including changelog)
and Makefile to rename xinput to xinput.sh.
Committed to xinitrc-4.0.1-1, built into FC3 devel. Please test. |
xinput currently has hard-coded configuration code for each of the various Input Method configurations of the CJK locale. It would make maintenance of xinput much easier if all the configuration code was moved out into separate scripts packaged individually with each IM client. Then xinput could just source the script appropriate for the locale, and it would become very simple. Tagoh and I discussed this idea a couple of days ago on irc and basically we came up with the idea that there should be a directory say /etc/X11/xinit/xinput.d/ that would contain symlinks: xinput-hi_IN -> /usr/share/xinput.d/htt xinput-ja_JP -> /usr/share/xinput.d/kinput2-canna xinput-ko_KO -> /usr/share/xinput.d/nabi xinput-zh_CN -> /usr/share/xinput.d/htt xinput-zh_TW -> /usr/share/xinput.d/htt which would allow multiple input methods to be installed for the same locale and for sites to be able to change the default IM per locale by changing the symlinks (as Tagoh suggested using alternatives would surely be the best way to handle this). [By default of course all the symlinks (installed by iiimf) would be to htt since that is our default IM for fc2 but I put in various examples above to illustrate what is possible.] Users would still be able to override the system default by setting XIM in their ".i18n" file, which would result in /usr/share/xinput.d/$XIM being sourced instead. All the actual files in /usr/share/xinput.d/ will be maintained by the corresponding packages, and this will also make it much easier to add new IMs in the future without having to edit xinput everytime, or users having to resort to using ".i18n" for this. I have already started a test implementation of this, which I hope to have ready shortly: I'll add it here when I have tested it.