ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
st3r4g has joined #wayland
ekurzinger has joined #wayland
<ekurzinger>
To any compositor hackers out there, do you ever find your VT frozen after a compositor crash? And if yes, do you know of any way to recover short of rebooting?
<ekurzinger>
It only happens to me occasionally, but it's annoying nevertheless
<dottedmag>
Are "names" of objects in registry required to be more-or-less contiguous, or can server assign arbitrary uint32 values to them?
<emersion>
libwayland-server might have a particular pattern, but from a protocol PoV they're pretty much opaque
leon-p has joined #wayland
<dottedmag>
Yeah, I'm mostly interested if any common client libraries will try to allocate ton of memory upon seeing registry object 0x1000000
<emersion>
libwayland-client won't care too much about registry names
<emersion>
to libwayland-client, registry events are just regular events
<dottedmag>
OK, and I can hope Qt and GTK do not do anything stupid in this regard. Anyway, easy to test, if anything blows up, it will blow up at startup.
<emersion>
so you're scared about a client using registry names as an array index?
<dottedmag>
Yep
<emersion>
i've never seen that, but you never know…
<dottedmag>
I don't think there were any compositors that used large numbers as registry "names", yeah.
<LaserEyess>
is that the issue here? this is on fcitx's end and it needs v2? Because in everything *except* kitty fcitx works and has a pre-edit window
<Arnavion>
At the very least, different versions == different protocols
<LaserEyess>
right but it seems to be working regardless of that
<LaserEyess>
(except in kitty)
<Arnavion>
They're probably not using the protocol but the fallback method you mentioned?
<LaserEyess>
the fallback method is specifically for GLFW which supports IMEs via ibus's dbus protocol
<LaserEyess>
on GTK, for firefox for example, I have GTK_IM_MODULE=fcitx5
<LaserEyess>
so maybe that has explicit support for fcitx (??)
<Arnavion>
If you have GTK_IM_MODULE, then it's not using the wayland protocol
<LaserEyess>
ok
<Arnavion>
GTK_IM_MODULE and QT_IM_MODULE are the toolkit-specific methods
<LaserEyess>
what a mess...
<Arnavion>
(They're how I use regular non-wayland fcitx under sway in firefox etc)
<LaserEyess>
I guess the last question I have is that what I'm specificallyt missing is the pre-edit window, for example for japanese when you convert kana to kanji
<LaserEyess>
the actual input method still works, I just have to do it blindly
<LaserEyess>
I guess that's just the dbus protocol and the window doesn't work on wayland?
<Arnavion>
Works fine for me in firefox
<LaserEyess>
for me as well
<LaserEyess>
just not kitty
<Arnavion>
So you are able to type and input kana and convert it in kitty? *Only* the window with the numbered choices is missing?
<LaserEyess>
correct, I can even hit tab (which is convert to first entry) and it works as expected
<LaserEyess>
so for example
<LaserEyess>
説明
<LaserEyess>
I typed that blind but I knew those kanji were the first choice for "setsumei"
<Arnavion>
I have no idea how that's happening then
<LaserEyess>
so `s e t u m e i [tab]` did indeed produce what I expected
<LaserEyess>
I just couldn't see it
<Arnavion>
Can you see the kana forming as you type or does that also not show?
<LaserEyess>
nope, blank
GentooPhysicist3 has quit []
<Arnavion>
Yeah, no idea
GentooPhysicist3 has joined #wayland
GentooPhysicist3 has quit []
<LaserEyess>
frustrating
dcz has quit [Ping timeout: 480 seconds]
GentooPhysicist3 has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
<emersion>
LaserEyess: sway is still missing pre-edit popup support