Xorg: None of the input methods work

[sixtyfive]

This was originally a comment on #83.

After installing rofimoji via pip (rofimojo --version gives rofimoji 5.2.0) I was hoping to be able to input smileys, etc. into apps such as GEdit. Unfortunately, none of the hotkeys work properly:

• Enter and Alt+T do nothing
• Alt+P works after a few seconds; alas, all of X is unresponsive afterwards, until Alt+Tab is pressed twice

Running something like xdotool type $'\u2192' from gnome-terminal works fine. Running echo $'\u2192' | xsel -i and then hitting the middle mouse button also works fine. Both xclip and rofi are installed as well, although I'm trying to use rofimoji in standalone mode.

In case it matters, I'm on an old ThinkPad X200 with two screens (one @2560x1440, the other @1920x1200) running Solus Linux with the Budgie desktop environment.

[fdw]

That does sound weird. Can you try to configure the typer manually to xdotool? I can imagine that nothing happens because, for some reason, it uses something else.

Regarding the unresponsive X, maybe it is related to this xdotool bug? If you hold the shortcut a bit longer, does it change anything?

[sixtyfive]

Hi! So, -a type --typer xdotool doesn't help - there's still nothing being typed when hitting Enter.

I've now found that either of -a clipboard --clipboarder xsel|xclip will cause Enter to insert the desired character after about 5 seconds, during which I may continue typing blindly. Once the delay is over, the selected character plus everything that was typed afterwards, appears in Gedit all at once. No Alt-tabbing necessary.

That's still annoying, but at least usable, so thank you! Unfortunately, in Firefox it causes whatever was already on the clipboard to be pasted; the selected character never gets put into the clipboard before that. I'm guessing that's somehow related to the known bug you talk about in the README.

[fdw]

The Gedit thing sound like something is blocking or just very slow. Then, as soon as it was pasted, the other typing events can be processed quickly.

That Firefox thing is weirder. Yes, you cannot type into Firefox directly, but the -a clipboard workaround is still supposed to work here.

Are you using a clipboard manager?

[sixtyfive]

Sorry if me mentioning the name of a specific application was misleading - the delay/block (?) occurs everywhere, be it Qt or Gtk or Tcl/Tk, be it a single-line text entry or a multi-line text area. Doesn't matter.

No clipboard manager that I'm aware of. Budgie is in part based on Gnome3 ... perhaps there's something built-in working in the background somewhere?

Today evening I should be able to power the laptop off and then will try again after it has booted afresh.

[fdw]

Do you have any new information here?

I think recent Gnome 3 versions run on Wayland, don't they? Could that be part of the problem?

[sixtyfive]

I'm on Solus and so far they've been refusing to switch to Wayland. Part of Budgie is indeed based on Gnome, but it's all X. Forgot about it, but will try tomorrow (laptop is okay to be rebooted now).

[sixtyfive]

So, the blocking delay is at around 2 seconds now, which is quite bearable, considering I only need to use it a few times every day. It's the same now in Firefox as everywhere else: 😊. Thanks for looking into it! I don't think I have either the knowledge or the patience required to figure out the delay-part, and otherwise it's functional now, so, closing.

[fdw]

Alright, good luck then!

If you do want to dig deeper: I suspect the call to xdotool is slow and blocks the system.