Use spell flag for spelling checking feature. Add xvnkb env file for those who want to enable xvnkb by default without touching bashrc
Created attachment 30717 [details] Ebuild for xvnkb
Created attachment 30718 [details] ebuild for xvnkb
Created attachment 30719 [details] env file for xvnkb
Yeah, I think it is a good idea to add sample env.d file for xvnkb, but the last time I tested it it didn't work. (LD_PRELOAD was ignored) If it works alright, I'm pretty happy to include it.
There is a problem with env-update (see bug #50090). If you already have a LD_PRELOAD set in env.d. It may override xvnkb. Other than that, i don't know why it didn't work for you. Is LD_PRELOAD in /etc/profile.env correct?
Hum, it seems if I use rxvt, rxvt-unicode, konsole and gnome-terminal LD_PRELOAD is preserved. However, if I use xterm and mlterm, it gets cleared. (I mainly use mlterm atm) Which terminal emulator are you using?
I'm using gnome-terminal atm. Tested with xterm ok. I'm emerging mlterm. I once failed to use xvnkb with xterm on Red Hat because xterm was suid. Can you check whether your xterm is suid?
Checked mlterm. Suid problem. chmod a-s /usr/bin/mlterm, then everything is fine ;)
Thanks for the test, now i understand. (My xterm is suid and mlterm is sgid) You may want add einfo (or probablly ewarn) for that in pkg_postinst().
Created attachment 30866 [details] Ebuid for xvnkb New ebuild, suid/sgid warnings added.
Umm.. because bug #50090 was resolved as WONTFIX. Should I remove 01xvnkb file?
Hum, I have the same impression. For example, LANG shouldn't be defined by system side but user side. LD_PRELOAD here is similar to LANG in this case (input methods are a matter of choice). We can assume that most Gentoo users are in fact root on their system and noone else uses that system, but theoretically system side and user side are different. Anyhow, if it's not going to be implemented by Portage, we better not add it.
Created attachment 31028 [details] Ebuild for xvnkb Deal. Remove env file.
Updated
pclouds, there's no need to reassign bugs away from cjk in order to close them. or maybe we should have a cjkv herd?
It was not him but me who reassigned this bug, because he hasn't yet been in cjk herd (though he said he would join us). I think it's a good idea to have cjkv herd rather than cjk herd. We might need someone to take care of Korean packages, then... (I'll ask mithrandir again about it)
I see cjk herd as a non-europe language herd. What if one day we get Thai support or Arabian support ;)
Good point ;) But it's not always true. We have middle-east herd for bidi languages. So cjk(v) doesn't mean "non-european support". Is it time for us to create "m17n" herd or something similar? (cjk and middle-east would be part of m17n)
