Description of problem: There is no fcitx-anthy package. It seems that fcitx is being more developed than ibus, and, even when I build from source, it is easier to use. Fedora has had it available since F19 or F20, and it would be nice to have in RHEL7 Additional info: For me (and possibly others) ibus is becoming increasingly problematic, whereas on every other major Linux distribution, as well as FreeBSD, fcitx-anthy and fcitx-mozc are available as packages.
I should add that I've gotten the Fedora-20 to work with the fcitx that's available in the repos, which I found here. http://apt.declera.com/f20/os/x86_64/os/Packages/f/fcitx-anthy-0.2.0-2.fc20.x86_64.rpm So maybe rebuilding it for CentOS-7 wouldn't be that hard. (He says, knowing little more than running rpm -ba whatever.spec.
That should have been rpmbuild -ba. :)
Addition of fcitx-anthy would benefit many users (including myself, a native Japanese). :-)
If it helps, here are links to the srpm and the rpm that I built with its spec file. (I made no alternations to the spec). http://srobb.net/fcitx-anthy-0.2.0-2.fc20.src.rpm Here is the rebuilt rpm. http://srobb.net/fcitx-anthy-0.2.0-2.el7.centos.x86_64.rpm
fcitx-anthy-0.2.2-4.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a577696fcc
fcitx-anthy-0.2.2-4.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a577696fcc
(In reply to Akemi Yagi from comment #3) > Addition of fcitx-anthy would benefit many users (including myself, a native > Japanese). :-) What is the benefit? I think ibus-anthy is the best way.
(In reply to fujiwara from comment #7) > (In reply to Akemi Yagi from comment #3) > > Addition of fcitx-anthy would benefit many users (including myself, a native > > Japanese). :-) > > What is the benefit? > I think ibus-anthy is the best way. For me, as well as others, ibus has become increasingly problematic. In one case, I had to use a script to shift between English and Japanese with keyboard shortcuts. In addition, it seems as if ibus development has either slowed, or stopped completely, though I'm not positive about that.
(In reply to Scott Robbins from comment #8) > (In reply to fujiwara from comment #7) > > (In reply to Akemi Yagi from comment #3) > > > Addition of fcitx-anthy would benefit many users (including myself, a native > > > Japanese). :-) > > > > What is the benefit? > > I think ibus-anthy is the best way. > > For me, as well as others, ibus has become increasingly problematic. In one > case, I had to use a script to shift between English and Japanese with > keyboard shortcuts. Shift modifiers is not recommended in GTK but not IBus only. > In addition, it seems as if ibus development has either slowed, or stopped > completely, though I'm not positive about that. I don't understand it.
Regardless, I'm just asking for a package to be added that better fits my use case, that I find easier to use. :) Please don't take it as an anti-ibus thing, I'm just asking that fcitx-anthy be added.
So you don't have a clear reason but asked a new package for EPEL. It's my point why I asked.
I feel that you are making this into an argument. I see no point in criticizing a package if I don't need to use it, but as mentioned in the original request, ibus frequently doesn't work properly for me. So, that's my reason. I dislike ibus, it requires far more effort, for my circumstances, to get it to work properly. If you feel that's not valid, that's fine, but for me, at least, and, though my evidence is only anecdotal, for others, it has become problematic and fcitx does a better job.
(In reply to Scott Robbins from comment #12) > I feel that you are making this into an argument. I see no point in > criticizing a package if I don't need to use it, but as mentioned in the > original request, ibus frequently doesn't work properly for me. I don't mind whether you request fcitx. But if you say ibus does not work properly, I'd look at what ibus does not work for you. Regarding to the Shift modifiers, seems your usage does not meet the GTK behavior. And I wonder if you have a subscription of RHEL, you could ask an RFE.
I don't have a RedHat subscription. I most often use Japanese in a urxvt or st xterminal,though I do make use of it in GTK apps at times. I did work around issues with ibus for awhile, but I'd prefer to not have to do so. It does seem that if one uses Gnome, or other full desktop environment, they're less likely to run into issues, but I prefer openbox or dwm. I suspect that as Fedora already has fcitx-anthy it will eventually make its way into RHEL, but I'm just trying to expedite it.
(In reply to Scott Robbins from comment #14) > I don't have a RedHat subscription. OK and then your request is still low priority. > I most often use Japanese in a urxvt or st xterminal,though I do make use of > it in GTK apps at times. ibus-setup is made by GTK and the shortcut key settings is one time only rather than the terminal applications. Now I wonder if you understand CLI supports the Shift modifiers without using ibus-setup. > I did work around issues with ibus for awhile, but I'd prefer to not have to > do so. It does seem that if one uses Gnome, or other full desktop > environment, they're less likely to run into issues, but I prefer openbox or > dwm. ibus fully supports the desktops. Seems you don't have clear reasons when you say ibus does not work for you. > I suspect that as Fedora already has fcitx-anthy it will eventually make its > way into RHEL, but I'm just trying to expedite it. It's fine but I just wonder why you try to use fcitx in RHEL without subscriptions. For me, it's easier to setup Shift modifiers with CLI than installing other IM frameworks. It's up to you but if you have the problems in ibus, I'd understand them with detail.
There are certainly times when ibus has worked perfectly for me. If I did a fresh install and put in ibus, 9 times out of 10, it should work the way I want it to. This bug, though, is for adding fcitx. It's a bit like (in the old days) saying we have pine, why do we need mutt? I, and just about anyone who has used RH or CentOS for Japanese input, certainly appreciate the hard work that has been done with ibus-anthy. I've said problematic "for me", and also qualified that with at times. :) With all due respect, whether ibus works or doesn't isn't that relevant to this bug report. Yes, it usually works very well, but I prefer fcitx. As someone once said in an old pine mutt debate, people pull up all sorts of technical reasons to justify what is, in the end, an emotional decision. So, though I'm not a subscriber and therefore am low priority, I have followed procedure and requested a package that I want. Other packages that accomplish the same thing are not really relevant to the discussion. I certainly am grateful for your work on ibus which has enabled me to easily input Japanese on CentOS for many years.
Sounds good. Thank you for the discussion. If you have any questions for IBus, it would be good to chat in #ibus @irc.freenode.net
fcitx-anthy-0.2.2-4.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.