Dead keys not working after activating shin

[Zachu]

Hey!

I'm having problem with Finnish keyboard layout containing multiple characters as Dead Keys. Keys such us ~ or ^ require me to press the ~ key and then space to enter only the given character. I can also combine them by pressing ~ and a for example to create ã.

I have all the keys working correctly, but after running ibus engine shin (and running a command through that) I no longer have working dead keys anywhere. Pressing for example ~ produces nothing.

Restarting ibus with ibus restart fixes this issue, but it comes back after every new launch of shiv.

Some details

Using finnish keyboard layout

$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     fi,us
variant:    ,
options:    nbsp:none

Using the latest version of shin I guess

$ git rev-parse --short HEAD
2f76026

Running on POP!_OS 22.04 (so pretty much Ubuntu 22.04) with GNOME 42.3.1

$ lsb_release -a
No LSB modules are available.
Distributor ID: Pop
Description:    Pop!_OS 22.04 LTS
Release:    22.04
Codename:   jammy

$ gnome-shell --version 2>/dev/null
GNOME Shell 42.3.1

[Zachu]

Hmm... Apparently after running the shin engine I would need to re-enable xkb:fi:classic:fin with ibus engine xkb:fi:classic:fin to get them working again. I'm kinda unfamiliar with ibus though so it appears that you can only have one engine on at a time, and enabling shin would disable others. As I see there currently there isn't an easy way I could toggle the xkb:fi:classic:fin back on after shin has done it's business since the ibus command exits rightaway.

[Zachu]

Actually now that I found out about this whole ibus thing I think I enjoy xkb:fi:nodeadkeys:fin more and it doesn't seem to break after running shin :grin: So personally I think I'm fine learning to use the previous dead-keys without them being dead-keys actually. But for others who do use dead-keys this is probably still very relevant

[p-e-w]

I can partially reproduce this. For me, dead keys still work after Shin exits, but unlike before, I don't see composition previews for them anymore.

One confusing aspect of IBus is that it considers regular XKB keyboard layouts to be "input engines" in some sense, even though input engines themselves also use a keyboard layout.

What is the output of ibus engine on your system before activating Shin for the first time?

[Zachu]

Actually seems to be:

$ ibus engine
xkb:us::eng

Running shin unsets the previous engine, and setting it back to what it was actually doesn't set something back up cause then my keyboard layout is fully in en/US layout, and dead keys not working.

$ ibus engine shin

$ ibus engine

(process:33469): IBUS-WARNING **: 14:46:35.847: ibus_bus_call_sync: org.freedesktop.DBus.Properties.Get: GDBus.Error:org.freedesktop.DBus.Error.Failed: No global engine.
No engine is set.

$ ibus engine xkb:us::eng

$ ibus engine
xkb:us::eng

# At this point dead keys are not working, but also my whole keyboard layout is now en/US

Either one of these fixes my dead keys and my keyboard layout

$ ibus engine xkb:fi:classic:fin
$ setxkbmap fi

Disclaimer once again: I don't know anything about this ibus thing :D

[0unknwn]

I have a similar problem: The dead keys are not working in shin, so I can’t use ^. Sometimes they are also not working afterwards.

[p-e-w]

This is pretty strange. Already before activating Shin, ibus engine reports a US layout, but that layout is not really active. I guess this constitutes a bug in IBus.

My hypothesis is that actually, no engine is active initially, which for some reason is misreported as a US layout. Explicitly setting that layout does activate it, with the result as reported by @Zachu.

Of course, Shin could just switch IBus to the correct engine when quitting, but the problem is, how to determine the "correct" engine? Checking which engine was active before would lead to the US layout being selected, as demonstrated above.

[Zachu]

Would shin even have this information out of box since you start it by enabling engine shin? Then if shin would check the active engine, it would get shin as a result :)

If shin can get this info out of the box then wouldn't that anyway be the correct way, to restore the previous active ibus engine after running? I guess it could be left for users to make sure they have set the engine correctly before launching shin.

Other way that comes to my mind would of course be some sort of a configuration option. restore_ibus_engine: xkb:fi:classic:fin or something of that sorts.

[p-e-w]

Would shin even have this information out of box since you start it by enabling engine shin? Then if shin would check the active engine, it would get shin as a result :)

I actually tested this a few weeks ago! Believe it or not, when Shin starts, IBus still reports the previous engine over DBus. My original plan was to do exactly that, switch back to the previously active engine. But then I discovered that just quitting Shin has the same effect, and is much simpler.

Except it now turns out that it's not quite the same effect after all. So I'll probably revisit this idea, and tell people to manually set their input engine before using Shin for the first time.

Still, this sucks a little. I'd prefer if people didn't have to do this manually. On the bright side, this will make Shin work properly if you actually do use other input methods like Pinyin, which it currently doesn't.

[Zachu]

One addition to this issue btw.

One thing that does break each time I activate shin even if I set ibus engine xkb:fi:nodeadkeys:fin initially is my CTRL + SHIFT + e` emoji picker. I'm unsure if it's Pop!_OS thing or GNOME thing, but anyway =)

After running shin I have to set the ibus engine back again to make the emoji picker work.

[tomatic]

Couldn't you just write a bash script for launching shin that first gets the active engine, activates the shin engine, and then restores the previous engine after shin exits?

[Zachu]

That is exactly how I'm running shin right now. And while I don't have any immediate problem with that I'm also not confident it's the way things should work by default. By breaking things without user implementing workarounds 😅

[tomatic]

Cool, glad to know that that works at least.

And I agree, this workaround shouldn't be necessary. Seems like it might be IBus' fault, not shin's. Unless there's something weird about how shin exits.