i3 WM position of prediction window

[JustSaX]

Hi Mike-Fabian

Is there a way to handle the position of the prediction window on i3 WM?

Currently, I have it on the first of my three screens on the right-hand side. But I would like to have it closer to the app I'm actually writing in.

Thanks!

[mike-fabian]

Can you give some more details please:

• what kind of programs are you typing into? Does this happen with all of them or only with some of them? Does it depend on the toolkit of the program? (Gtk3, Gtk4, Qt4, Qt5, old X11 programs like xterm, ...)
• make a screenshot how your screen looks like
• what distribution are you using?
• which versions? (versions of the distributioņ and the programs used)

I am using i3 myself and currently do not have that problem.

• i3-4.20.1-1.fc36.x86_64
• Distribution Fedora 36
• gedit-42.0-1.fc36.x86_64 (This uses Gtk3)
• gnome-terminal-3.44.0-1.fc36.x86_64 (this uses Gtk3)
• gnome-text-editor-42.1-2.fc36.x86_64 (This uses Gtk4)
• xterm-371-1.fc36.x86_64 (old X toolkit)
• anki-2.1.15-6.fc36.noarch (uses Qt5)
• libreoffice-writer-7.3.3.2-1.fc36.x86_64 (don't know which toolkit this uses)
• emacs-27.2-11.fc36.x86_64 (old X toolkit)

I don't have this problem in any of these at the moment, the prediction window is always close to my current cursor position.

[JustSaX]

Thanks for the quick reply.

I figured out for everything I write on my main screen, I have the prediction window close to the cursor. If I write on one of the other screens the prediction window will stay on the corner of the first screen.

This is independent of the app I use (Terminal, Firefox, Gedit, ...).

I'm using:
Regolith 1.6.0
i3 4.19.1
Ubuntu 21.10

[mike-fabian]

Oh, very weird, I have never seen that. I am also using 3 screens, the screen of the laptop and two more monitors connected to the docking station. On 3 screens in all applications, the candidate window pops up close to the cursor.

[mike-fabian]

This is probably very hard for me to replicate because if I install Ubuntu 21.10 in a virtual machine, I have only one screen there and you say on your main screen it works.

[mike-fabian]

ibus-typing-booster most likely has nothing to do with this, ibus-typing-booster has no control over where this candiate window pops up. ibus-typing-booster just requests such a window and then ibus pops it up. If you use any other ibus input method, for example the Japanese input method ibus-anthy, you will see the same problem with the wrong position of the candidate list.

So this might be a bug in ibus or it might have something to do with i3.

There are many bugs about wrongly positioned ibus candidate windows and sometimes they are bugs in ibus and sometimes ibus gets wrong information from the toolkit or the Wayland compositor or something like that.

Does that happen only when you use i3 or does it also happen when you use a different desktop?

[mike-fabian]

I have no idea at the moment. It doesn’t happen for me even though I use i3 as well and I am also using 3 screens. I don’t think the difference in i3 versions is important (me: i3-4.20.1-1.fc36.x86_64 you: i3 4.19.1) as I am using this for many years already, so I certainly had i3-4.19.1 a while ago and had no problem.

Did you try Gnome Wayland or Gnome Xorg? This might make a difference.

Gnome is kind of a special case as far as the ibus candidate windows are concerned because Gnome draws these candidate windows. You see that they also look different on Gnome, they have white letters and a black background and colours in the candidate lists are not possible currently in Gnome.

On other desktops (i3, XFCE, Plasma, ...), ibus draws the candidate windows and they have (usually) black letters and a gray background and colours are possible so the options to use different colours for “user database suggestions”, “spellchecking suggestions”, and “dictionary suggestions” work on the other desktops but not on Gnome.

As Gnome draws the candidate windows, bugs in the positioning of the candidate windows are often different on Gnome compared to other desktops. Whether using Wayland or Xorg also often makes a difference.

i3 uses Xorg, not Wayland. Therefore, it might be interesting to check whether the same problem you see occurs when using for example XFCE. XFCE also uses Xorg and it lets ibus draw the candidate lists so this is quite close to the situation on i3. If the same problem happens with XFCE, then it has probably nothing to do with i3.

[mike-fabian]

I checked what ibus specific stuff I have in my ~/.config/i3/config and it is only this:

exec ibus-daemon -drx
# Make the “floating toolbar” window of ibus “sticky”
# (This does not seem to make any difference though, enable seems to be the default
# already for floating windows):
for_window [instance=ibus-ui-gtk3] sticky enable

So my i3 configuration does not seem to be the reason why I do not see this problem.

[mike-fabian]

I just checked that not only the “floating toolbar” of ibus but also the candidate lists have the id “ibus-ui-gtk3”!

So maybe the line

for_window [instance=ibus-ui-gtk3] sticky enable

does have something to do with the problem. Although if I change it to

for_window [instance=ibus-ui-gtk3] sticky disable

and restart i3, it still works for me.

[JustSaX]

Ok, I figured out how to make it partly working.

If I execute /usr/libexec/ibus-ui-gtk3 it works. But if I add exec /usr/libexec/ibus-ui-gtk3 to my i3 config. It doesn't work.

Thats's the output of /usr/libexec/ibus-ui-gtk3 in the terminal:

[mike-fabian]

It is surprising that starting /usr/libexec/ibus-ui-gtk3 from the command line makes it work 🤔

When I start /usr/libexec/ibus-ui-gtk3 from the command line, I see the same messages you see.

But one is not supposed to do this, ibus should do this automatically.

I have only

exec ibus-daemon -drx

in my ~/.config/i3/config but in the process list I see:

$ ps aux | grep ibus 
mfabian    14900  0.6  0.0 808716 13380 ?        Ssl  10:25   0:10 ibus-daemon -drx
mfabian    15002  0.0  0.0 450452  7308 ?        Sl   10:25   0:00 /usr/libexec/ibus-dconf
mfabian    15003  0.4  0.3 798920 58248 ?        Sl   10:25   0:07 /usr/libexec/ibus-ui-gtk3
mfabian    15004  0.2  0.1 523800 31060 ?        Sl   10:25   0:04 /usr/libexec/ibus-extensio
n-gtk3
mfabian    15006  0.0  0.1 442040 21520 ?        Sl   10:25   0:00 /usr/libexec/ibus-x11 --ki
ll-daemon
mfabian    15014  0.0  0.0 449760  5600 ?        Ssl  10:25   0:00 /usr/libexec/ibus-portal
mfabian    15032  3.3  1.6 828852 259708 ?       Sl   10:25   0:51 /usr/bin/python3 /usr/shar
e/ibus-typing-booster/engine/main.py --ibus
mfabian    15104  0.0  0.1 495192 21408 ?        Sl   10:25   0:00 python3 /usr/share/ibus-an
thy/engine/main.py --ibus
mfabian    15127  0.0  0.0 376520  7220 ?        Sl   10:25   0:00 /usr/libexec/ibus-engine-s
imple
mfabian    21643  0.0  0.0 222700  2480 pts/6    S+   10:50   0:00 grep ibus
$ 

So /usr/libexec/ibus-ui-gtk3 has been started, but that has been done automatically by ibus, I did not do that manually.

Do you have a command to start ibus-daemon in your ~/.config/i3/config like I have?

[mike-fabian]

Does it help when you add

exec ibus-daemon -drx
# Make the “floating toolbar” window of ibus “sticky”
# (This does not seem to make any difference though, enable seems to be the default
# already for floating windows):
for_window [instance=ibus-ui-gtk3] sticky enable

to your ~/.config/i3/config?