00:28 <Guest50> ifreund: please find a screenshot at https://0x0.st/Xs64.png Credit can go to "Anon" or similar

00:40 <ifreund> Guest50: thanks!

00:40 <NickH> Plausible deniability 😉

00:40 <ifreund> I did think that theme looked suspiciously familiar...

00:41 <ifreund> anyhow, I'm off to bed for now o7

00:46 <laura_> Heya all. I'm wondering if there's a way to list all current keybind mappings?

00:46 <NickH> There isn't

00:46 <laura_> Ah that's a shame. Thanks for letting me know at least

00:46 <NickH> Easist way is to read you init file

00:46 <NickH> s/you/your

00:48 <laura_> Yeah I'm doing that, trying to debug why a mapping seems to have been overwritten with something else. When I manually remap it with riverctl it says it's overwriting an existing mapping and then after manually remapping it it works properly, but beforehand that mapping doesn't seem to do anything. Not the biggest deal in the world as it's not a mapping I use often, but would help to see what mystery action it's been mapped to

00:49 <laura_> nvm, just as I was typing that message I realised the problem—I renamed a script I was calling in the mapping and forgot to change it in the init script lol, my bad

02:05 <NickH> I'm having a look at waylock. I'd put off trying it since the README.md didn't mention anything about the input-color feature.

02:06 <NickH> One of my laptops has a slightly flaky keyboard so not having feedback on keypress is less than ideal.

02:07 <NickH> So after actually digging into the code I dound the input-color option and decided to give it a try.

02:08 <NickH> So waylock is works for me once I changed /usr/local/etc/pam.d/waylock to "auth include login"

02:10 <NickH> However input-color doesn't work as I anticipated: I had assume that on each keypress the screen would briefly switch to input-color and then switch back to init-color.

02:11 <NickH> Instead it remains input-color until unlock is either succesful or fails.

02:12 <NickH> I wonder if this alternate behaviour would be considered a reasonable option?

02:26 <leon-p> I wonder if a screenlocker version of wayprompt would make sense...

02:32 <NickH> That would be cool.

02:34 <NickH> How hard do you think it would be to implement?

02:48 <leon-p> The important bits are already there (text input, buffer with fancy UI rendered to it)

02:49 <leon-p> the one big requried change would be to attach that buffer to a subsurface instead of a layer-surface, but that is something I want to do anyway, because I want to use a layer-surface in the background to darken the screen

02:49 <leon-p> since singel-pixel-buffer allows me to do that with basically no memory penalty

02:50 <leon-p> but that is like number 3 or 4 on the to-do list, the top two spots are riverguile's widget system right now

02:51 <leon-p> btw, I don't think I have mentioned it here yet, just in the other channel, but wayprompt now also has an ssh-askpass implementation

02:51 <leon-p> just a simple shell wrapper around the CLI version

02:59 <leon-p> but as I said, first I want to figure out how to sync scheme and wayland lifetimes so I have a better way to refer to arbitrary widget objects in scheme code than just some made-up ID. That is border-line for outputs already, but the foreign-object thing in guile really isn't made for that...

03:00 <laura_> ifreund, you're also free to use this :) no credit/anon credit is preferred (although my name's there anyway lol, still) https://0x0.st/XsIq.png

03:01 <NickH> Dracula theme?

03:02 <NickH> And wayneko!

03:09 <leon-p> my cat code is surprisingly popular

03:11 <laura_> rosé pine theme :)

03:11 <NickH> I have it on my machine, but don't usually run it

03:12 <NickH> First I've heard of that theme

03:12 <laura_> and yes, I just installed wayneko today. It's really cute, doesn't get in the way so I just have it running at all times as a little decoration

03:12 <leon-p> if it gets too distracting, I just pushed someones patch upstream introducing a "sleepiness" option to make neko sleep a lot more

03:13 <NickH> Mind you since I settled on gruvbox a couple of years ago I've not been looking

03:14 <leon-p> the only thing missing now are a few more different animal types besides neko and the dog and I think that project at least is basically done. There were more bitmaps for different characters in oneko, but they were a bit too tacky and/or tasteless IMO

03:15 <leon-p> a pufferfish would be kinda neat

03:16 <laura_> Gruvbox is really nice, it was a runner up for rosé pine when deciding on a colour scheme for my current setup

03:16 <laura_> I love wayneko though, makes me nostalgic for desktop pets back in the day

03:18 <leon-p> you can also colour the cat btw to make it fit your theme if you like

03:24 <NickH> https://0x0.st/XsIu.service

03:47 <leon-p> huh, I think we have a bug in the keyboard code again: press a key with keyboard focus on one surface, surface gets destroyed, keyboard focus moves to another surface, key gets released, the new surface will get the key up event

03:47 <leon-p> do we want that?

03:48 <leon-p> maybe between normal toplevels that's reasonable, but if we jump between different shells, i.e. layer-shell to toplevel, it's not so clear anymore if that is the right behaviour

03:49 <leon-p> like, many widgets get closed with escape (fuzzel, wayprompt, etc...). Should the "escape released" event really be forwarded to the focused toplevel?

05:33 <tiosgz> leon-p: the surface gets the key on wl_keyboard.enter, so it definitely makes sense to send the release event

05:34 <tiosgz> i don't know if we could send no keys on enter though, which would then need no release event

05:34 <tiosgz> (but then you couldn't, for example, ctrl-d-d-d-d to close a bunch of terminals)

05:35 <leon-p> fair, but if you f.e. close fuzzel with escape, I doubt anyone would expect the focused view to also receive that event

05:36 <tiosgz> is this any different from closing a toplevel with escape?

05:36 <tiosgz> (assuming the app accepts this)

05:36 <leon-p> technically or philosophically?

05:37 <tiosgz> technically i guess. dunno what you mean now

05:38 <leon-p> here is a real-world example: you have a fullscreen video in firefox, you open some layer shell widget on top. you close the widget with escape. firefox also receives the escape key events and evits fullscreen.

05:40 <tiosgz> i recall this issue. but were escape bound to something in tiled mode as well and ff got the escape key from a just-closed toplevel, it's the same, innit?

05:40 <leon-p> or: you use Enter to confirm a selection in fuzzel or wayprompt, the focused view also receives the enter event and of course treats it like an explicit input from the user, f.e. starting some task

05:40 <leon-p> tiosgz: not quite, that old issue was about maps

05:40 <tiosgz> i believe that's a client-side misinterpretation

05:40 <tiosgz> ah

05:41 <leon-p> the client has no way to differentiante, there is no room for interpretation

05:41 <tiosgz> there is. wl_keyboard.enter is not wl_keyboard.key (or what the event is)

05:42 <tiosgz> we could work around this anyway, but i personally would prefer not to

05:43 <leon-p> why not?

05:43 <tiosgz> (in which case, mod keys would still be better passed to the enter event)

05:43 <leon-p> mods are not the issue

05:44 <tiosgz> idk, just... we're doing what we're supposed to do? personal preferences

05:44 <leon-p> arguably at least between layer-shell and views there should be separation

05:45 <tiosgz> then that's inconsistent. if we work around it, it should be everywhere (which is also way easier to do i'd say)

05:46 <leon-p> true, that's what I'd argue for

05:46 <leon-p> just that for the layer shell it's the most obvious

05:48 <tiosgz> well, anyway. i'll try to look into it tomorrow and open a pr if everything goes good (unless you're faster than me)

05:48 <tiosgz> but still i'd prefer not to have it in

05:49 <leon-p> while the other surface only gets the release event, to my knowledge there is nothing in the protocol that says clients aren't allowed to act on it. So lazy clients will respond to the release. We are basically just inviting weird behaviour here

05:50 <leon-p> again, when I close some layer shell widget, I think the focused view really should not recevie that very same event

05:51 <leon-p> I won't be faster, my social life does not allow me to do much more than complain right now 🐈

05:51 <leon-p> but you shouldn't spend time on code yet either, I would like to hear ifreund 's thoughts on this first

05:52 <tiosgz> leon-p: i believe i see what you mean, but to me an .enter,.key(...0) sequence is different from a .key(...1),.key(...0) one. i have the "advantage" of not making any client though

05:52 <leon-p> (as a related example, if you click the "X" button to close a window, you wouldn't expect that click to "pass through" to a lower window)

05:53 <leon-p> tiosgz: well, protocol events are one thing, observable behaviour another

05:53 <tiosgz> hmm. i wonder what events happen in the cursor case

05:56 <leon-p> I mean, in a perfect world, everyone would only let their client spawn actions for pointer / key / touch events if it receives matching press and release, but people are lazy

05:57 <tiosgz> don't we live in a perfect world? :D

05:58 <leon-p> I am afraid not, but I don't want to check

06:01 <leon-p> not the only keyboard annoyance with the layer-shell btw. Back when I was still maintaining lavalauncher, I wanted to add the feature to let users configure Ctrl-Click, basically holding a modifier while clicking on a button, to some action. That is basically impossible to do cleanly with the layer shell. I tried raising that issue but did not get very far...

06:02 <tiosgz> that's a focus-on-demand layer?

06:03 <leon-p> no, it's technically supposed to be a never focused layer, just a dock with buttons. I had a hacky implementation that changed keyboard focus state life.

06:04 <leon-p> you really don't want a dock to be focused, that is weird UX

06:04 <leon-p> s/life/live

06:05 <tiosgz> ah, the windows times when it happened too often that no window was focused

06:07 <tiosgz> well, back on topic. i have a similar issue with waybar's tray context menus, where i think this could be solved by giving the popups keyboard grabs. hasn't annoyed me enough yet though

06:08 <leon-p> I do want to get into writing a panel / dock again, but I'll definitely take a more ... maintainable approach next time lol

08:31 <ifreund> leon-p: I also think we are doing what we are supposed to do according to the protocol with regard to keyboard enter events fwiw

10:53 <sajcho> ifreund: This problem is not related to river. Sometimes our system freezes. See: https://dpaste.com/3EFRAD4CJ. Wlroots ver. 0.17.2. I'm not sure if it's my fault or wlroots.

10:58 <ifreund> sajcho: what river version?

10:58 <ifreund> oh, it says in the log. I forgot I made it do that :D

11:02 <ifreund> sajcho: why do you say "this problem is not related to river"?

11:02 <ifreund> that appears to be a river log...

11:07 <sajcho> Because I don't know what's causing it. River or wlroots.

11:07 <ifreund> how can I reproduce the issue?

11:08 <ifreund> It's almost certainly a river bug

11:08 <ifreund> a debug log would be useful as well, `river -log-level debug`

11:10 <sajcho> Good. I will try and report back.

11:41 <sajcho> Here is the river -log-level debug output. https://dpaste.com/7PRZKNAJ7. Keyboard and mouse stop responding.

11:59 <sajcho> I tried swaywm in ver. 1.9. Same problem with keyboard and mouse.

15:44 <The_Buhs> guile breaking my brain lol

15:51 <The_Buhs> I'm trying to re-create this https://bpa.st/AKKQ with this https://bpa.st/RBCA but I can't switch between tags and I have no clue what's wrong

15:52 <The_Buhs> My layout is also not working, everything spawns floating and stays that way, but I can figure that out after

21:28 <leon-p> The_Buhs: take a look at how I did the tags thing: https://git.sr.ht/~leon_plickat/river-config/tree/master/item/river/init#L222

21:28 <leon-p> notably, you do not need to unquote i if you already unquote the surrounding expression

21:29 <leon-p> also try running your init in a terminal, riverguile prints error messages which hopefully help debug the layout

21:30 <leon-p> and your (let* ) is invalid: your have (let* (tagmask (ash 1 i)) ...) when it should be (let* ((tagmask (ash 1 i))) ...)

22:53 <The_Buhs> <leon-p> The_Buhs: take a look at how I did the tags thing: https://git.sr.ht/~leon_plickat/river-config/tree/master/item/river/init#L222

22:53 <The_Buhs> that's what I based mine off of but I didn't understand how to change it since I don't have river-bnf

22:53 <The_Buhs> Thanks though, the info is helpful (hopefully) :)