[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: im-config | Use im-config on Wayland without uninstalling IBus (!5)



Hi again, Osamu!

On 2020-07-23 09:29, Osamu Aoki wrote:
Hi Gunnar,

I admit my misunderstanding of gnome-session code and I have related
questions to you.

Q1: Leaving GTK_IM_MODULE unset by gnome session is not just for
wayland but also for X.  Am I correct?

Well, if you ask the GNOME folks they'd probably answer 'yes'. But on X it works without serious issues to set GTK_IM_MODULE=ibus, which is the reason why GNOME on Wayland has been the focus in this long thread.

Q2: Leaving GTK_IM_MODULE unset or NULL string is that equivalent of
     setting GTK_IM_MODULE=xim .  Am I correct?

Well, let's not go back to setting xim now... Leaving it unset or "" makes it remain unset or "". GNOME via gnome-session does not bother about GTK_IM_MODULE.

The background of my question is below.

On Thu, 2020-07-23 at 08:11 +0200, Gunnar Hjalmarsson wrote:
On 2020-07-20 04:28, Changwoo Ryu wrote:
There's an issue about the on-screen keyboard with
GTK_IM_MODULE=ibus. IIRC it's about entering accented characters by
long-press.

Actually it does not show up. At all.

But it is not an issue for CJK users, as the current implementation
of GNOME on-screen keyboard is useless for CJK languages anyway.

That's a misleading description of the effects.

Debian's GNOME is shipped with GNOME on Wayland by default,

But Debian's GNOME has an option to be started on X, too.

True. Which would be a workaround. Not saying there are not workarounds. But I think we should focus now on the default config via im-config for the default Wayland option.

and both
ibus and im-config are there by default. With the current state of
im-config in the devel branch, the on screen keyboard (OSK) is
consequently broken by default for everyone.

We know that the GNOME developers have integrated IBus into the
desktop
in such a way that GTK_IM_MODULE is supposed to *not* be set to
"ibus",
at least not for Wayland sessions.

No wonder you know such details around this issue.

Author: Gunnar Hjalmarsson <gunnarhj@ubuntu.com>  2016-08-14 10:32:00
7060744a ("main: Don't override IM variables", 2016-08-13)

I somehow thought code around here was setting GTK_IM_MODULE.
I was wrong. In the gnome-session source, gnome-session/main.c


           {
                   gchar *ibus_path;
ibus_path = g_find_program_in_path("ibus-daemon"); if (ibus_path) {
                           const gchar *p;
                           p = g_getenv ("QT_IM_MODULE");

                           if (!p || !*p)
                                   p = "ibus";
                           gsm_util_setenv ("QT_IM_MODULE", p);
                           p = g_getenv ("XMODIFIERS");
                           if (!p || !*p)
                                   p = "@im=ibus";
                           gsm_util_setenv ("XMODIFIERS", p);
                   }
g_free (ibus_path);
           }

So in a plain language:
GNOME session checks if ibus-daemon available
   --> if not, don't bother any more for environment variables.
GNOME session checks if QT_IM_MODULE is not set yet
   --> if not, set it to "ibus".
GNOME session checks if XMODIFIERS is not set yet
   --> if not, set it to @im=ibus".

Precisely.

Previously the equivalent piece of code overrode whatever value was set by e.g. im-config. My commit changed it to the current code which is what makes it possible to use non-IBus frameworks on GNOME even if IBus is installed.

Interesting...  (This seems to be the root cause of my confusion.  I
somehow thought GTK_IM_MODULE was also set to ibus here.)

But this is also for X.  So even under X, GTK_IM_MODULE=xim is used
(not GTK_IM_MODULE=ibus).

This is not good for X.

The GNOME code in gnome-session is for X too, yes. But GNOME does not set xim. It does not set GTK_IM_MODULE at all.

This is what I pushed (and which was reversed later):

https://salsa.debian.org/input-method-team/im-config/-/commit/c2055cc4ba41a80167cb848c2035607ffb61f5f3#b0ea273a1df06073abf824ce18e441d7da00c259_9_9

And I still think that something along those lines would be the least problematic way for im-config to deal with GNOME on Wayland. Especially in the light of the fact that the ibus-hangul/mutter issue is about to be fixed.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj


Reply to: