On 2021-03-05 16:18, Osamu Aoki wrote:
On Thu, 2021-03-04 at 11:43 +0100, Gunnar Hjalmarsson wrote:GNOME favors IBus. That's hard to change. im-config also favors IBus. How about letting im-config fall back to IBus instead?I was a bit lost what exactly was discussed. As I re-read this bug report from Yoshino-san, its objective is automate ibus setting specific inputmethod (be it anthy or mozc). I don't have time to check its goodness, but its intent is step in right direction. I don't understand why we need to worry about fcitx or uim here.
While the direct purpose of this bug report is a proposal to add an auto setup script to ibus-anthy, the background is that gnome-shell has started to recommend ibus which makes it hard to set up a non-ibus IM at installation via tasksel meta packages.
[ @Osamu: I reviewed the MR: https://salsa.debian.org/input-method-team/ibus-anthy/-/merge_requests/2 and noticed an issue. It would be good if you could take a look. ]
More specifically: rename 21_ibus.{conf,rc} to e.g. 49_ibus.{conf,rc}??? This puts ibus in lower priority. Why? I don't understand the exact motivation. <snip> If the issue is package dependency of GNOME pulling in ibus package which causes trouble,
Yes, that's it.
cleaner solution may be intruducing dummy ibus- fake package which provide ibus for dependency. fcitx and uim may be made to depends on this ibus-fake package. Something like this seems simpler fix.
That might also address the problem. Not sure about cleaner/simpler, though. :)
Also, would adding a new binary, even if only a dummy, be allowed during soft freeze?
That would still make im-config let GNOME configure IBus for most GNOME users. But if uim is present, im-config would configure uim, and if Fcitx is present, im-config would configure Fcitx. Even if IBus is installed. Such a change would be based on the idea that if a non-IBus framework is present, the user is assumed to prefer it over IBus. (The choice of framework can still be changed by the user.) What do you think? I think that such a tiny change would compensate - from an IM POV - for the fact that gnome-shell started to recommend ibus.
Let me add that I'm not sure about my idea. Earlier on this bug report I wrote:
GNOME relies on IBus, and IBus is the only IM framework supported by GNOME. So when you use a non-IBus framework you do it at your own risk. For that reason I think it makes sense that the user needs to actively select a framework to be able to use a non-IBus framework on a GNOME desktop. It would be possible to change im-config so IM_CONFIG_PREFERRED_RULE is effective also with GNOME. But by doing so, Debian would make a choice behind the scenes resulting in a combination which is known to be fragile and break certain aspects of the desktop.
So you can rightly say that I contradict myself. :/ Maybe it's not a good idea to keep using tasksel to install non-IM input methods on the GNOME desktop.
-- Rgds, Gunnar Hjalmarsson https://launchpad.net/~gunnarhj
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature