02:48 <mx08> dnkl: Hah! I have also remapped the left ctrl to caps-lock :) It also works with the right ctrl for me (dumb me didn't check). Also thanks about the note about foot handling shortcuts before the shell, that makes sense...

02:48 <mx08> I'm using sway.

02:49 <mx08> I'm using a us layout with the alt-intl variant, and have the following input options set in my sway config: xkb_options ctrl:swapcaps_hyper,compose:prsc

02:50 <mx08> (It's not really an issue for me as I was not actively waiting for the prompt jumping feature. I mainly was wondering why it was happening and wanted to report it...)

03:03 <vipulogmx> While building foot 1.13.0 on bullseye with meson 0.62.1 i get the following error, it's probably because warnings are treated as errors and that's causing the stoppage, do let me know if it can be eliminated, here the error that comes up, https://ezup dev/p/u65ma7

03:04 <vipulogmx> https://ezup.dev/p/u65ma7

03:57 <Arnavion> It's not a warning. Your version of wayland-protocols is old enough that it's missing xdg_toplevel::configure_bounds

03:57 <Arnavion> It was added in v1.25, and Debian 11 seems to only have v1.20

03:58 <Arnavion> I assume it'll be fine to just #ifdef it like wm_capabilities is

04:22 <dnkl> Arnavion: vipulogmx: yeah, we can definitively #ifdef that too, similar to wn_capabilities

08:00 <dnkl> I don't usually run gnome, but when I do, it's always buggy 😴

08:01 <dnkl> (added a workaround in foot for mutter sending pointer enter events with a NULL surface, causing a crash in foot in the next motion event)

08:02 <n0r> Wait what xD. Of all Desktop environments Gnome has always been the least buggy to me. Though exept for Plasma, Xorg might be the one to blame for that :D

08:04 <dnkl> there's been lots of issues with their Wayland implementation

08:04 <dnkl> problem is it's usually the client (i.e foot) that crashes, not the desktop

08:05 <dnkl> do someone else gets blamed...

08:05 <dnkl> problem is likely they only, it mostly, test against GTK apps (this is just a guess though)

08:06 <dnkl> s/do/so

08:06 <dnkl> s/it mostly/or mostly

08:07 <dnkl> but you're right about plasma... at least for a long time their Wayland support was way behind, and really dodgy

08:07 <dnkl> haven't tested it in s while though. might be better now

08:20 <dnkl> and to be fair, Sway has had (still have?) their share of keyboard and pointer focus related bugs

13:29 <vipulogmx> Can you simplify what you folks meant by, " ifseffing similar to wm_capabilities"

13:30 <dnkl> vipulogmx: I'll push a patch tonight

13:33 <vipulogmx> Great

14:16 <dnkl> vipulogmx: https://codeberg.org/dnkl/foot/commit/eafff70439c650dba288d0ac05cd009510bf6205

14:17 <dnkl> that's on the master branch. I've also backported it to the 1.13 branch (meaning it'll be included in the next 1.13 patch release)

16:38 <anon> the profanity xmpp client freezes randomly when being used on foot

19:41 <Arsen> dnkl: been on plasma wayland for a while

19:41 <Arsen> some kde apps are still dodgy, but I haven't had issues like the ones you see on gnome

19:41 <Arsen> (even on an nvidia gpu! it's a miracle)

19:43 <Arsen> e.g. spectacle clearly isn't perfectly integrated yet (it still mostly behaves as an override window would on X: pretty poorly), and some KDE Connect features (injecting some kinds of input) don't work yet

19:44 <Arsen> I was intending on tinkering on these issues this summer bot other projects took priority, and so did academia/family, so it got pushed back pretty far

19:45 <Arsen> I do kinda wish kwin uses wlr instead of kwayland or whatever, feels like a waste to duplicate all that effort, but I can see why it happened somewhat

19:49 <Arnavion> There's a one-man fork of kwin that uses wlr. Not sure what its future is going to be

19:50 <Arnavion> ( https://gitlab.com/kwinft/kwinft )

22:42 <ifreund> to be clear, it use wlroots for the rendering and input backend parts

22:43 <ifreund> it still has it's own wayland protocol implementation that doesn't use wlroots building blocks