00:04 <ext0l> right now, my setup on sway uses a 2x2 grid layout for my 'chat client' workspace, but i tend to go with a more 'one main, several smaller' layout for the other workspaces. is this something i can replicate in river?

00:05 <leon-p> ext0l: yes

00:05 <leon-p> just not with the default layout generator

00:05 <ext0l> ah ok

00:05 <ext0l> yeah it looks like the layout protocol does specify the tag set

00:05 <leon-p> some of the community layout generators (like mine, for example) support per-tag layouts

00:05 <ext0l> which one is yours?

00:05 <leon-p> https://git.sr.ht/~leon_plickat/stacktile

00:06 <ext0l> neat, ty

00:06 <leon-p> if you use the --per-tag-config command flag, all layout configuration is per tag instead of global

00:06 <ext0l> got it

00:07 <ext0l> honestly this is one of the things that really interested me in river so this is good to hear

00:07 <ext0l> going to try converting tonight after my daily walk/dinner

00:09 <leon-p> ext0l: nice!

00:10 <leon-p> if you have any questions, you can of coruse come here. Just be aware that most people answering questions here operate on european timezones

00:11 <ext0l> yeah it's a 30-person channel for a niche window manager, i'm not expecting instant responses in any case :D

01:58 <elshize> hey, speaking of git send-email, just wondering, what email client are you guys using to interact with pathes and mail lists and stuff?

06:40 <ino> Hi! is there any way for blurring background? thanks!

06:43 <ext0l> i don't think so

06:44 <ino> oh. when i was using picom it had that "dual_kawase" algorithm for blurring. I was wondering if similar kind of blurring is available in river.

06:45 <ext0l> yeah, i don't think so. i miss it too (from having used sway) but afaik it's not trivial to implement

06:46 <ino> oww.

06:47 <ext0l> iirc wayfire is the biggest wayland impl that supports blur (outside of gnome/kde ofc)

06:48 <ino> wayfire is a 3D compositor, right? inspired from compiz

06:49 <ext0l> yeah, though you can just leave all the 3d stuff off ofc. i've never used it so i have no clue how good it is

06:51 <ino> I am having very good time with river! thanks to all the maintainers and developers of this project. i can now become more productive.

12:51 <ino> Hi! is there a way to reduce the gap between the layout and screen-edge persistantly? I have gone through the default `init` file, I have seen an option to use `super + alt + ctrl` keybinding to snap view to screen edges, but it makes the window float; and it is applied for only one window. is there any way to reduce/increase persistantly accross

12:51 <ino> all tags and windows? thanks! :)

12:53 <novakane> ino: gaps are handled by the layout generator so it depends which one you use. For example with rivertile you need to launch it with `rivertile -outer-padding 4`

12:53 <novakane> see rivertile(1) manpage

12:54 <novakane> note that you can't change it at runtime

12:54 <ino> Thank you novakane!!! you always help. sorry i forgot to check the man page. :))))

12:54 <novakane> ino: no worries

12:55 <ino> =D

15:27 <novakane> I started writing a draft article for the wiki on river protocols, what do you guys think? https://paste.sr.ht/~novakane/16ef1acec62147d2552771e6e1a49878ba7e1d87

15:28 <novakane> I hope there is no wrong information in it

15:31 <leon-p> novakane: I'll give it a read

15:31 <leon-p> you should probably mention that the language needs wayland bindings in the first paragraph

15:34 <leon-p> novakane: the most important part of the article is, IMO, the last part, where you list all protocols and what they can do. That is the number 1 thing people will look for.

15:35 <novakane> leon-p: it mentionned later but I could change it

15:35 <novakane> right I should change the order

15:37 <ifreund> yeah, definitely want to focus on river-specific information but link to more general wayland info

15:38 <leon-p> btw, I have some new ideas for river-toplevel. I should have working code sometime this week.

15:38 <ifreund> and the only protocol not currently planned to be replaced is river-layout-v3 fwiw, so I'm not sure documenting the current river-control or river-status is really worth it beyond what's in the XML

15:39 <ifreund> leon-p: cool, I'm currently super busy with work and exams but I'll try to get you a review when I can

15:39 <novakane> I didn't want to publish it yet in case there was too many mistakes, but once there is a good base, I'll add it to the wiki so you guys can edit it easily

15:39 <novakane> ifreund: Yeah I know I hesited I probably mention it

15:40 <leon-p> novakane: if you can provide a description of all the events and requests that is readable by mere-mortals without Wayland experience, I think that could be really nice

15:42 <novakane> leon-p: I'll try this, probably only for river-layout for now though

15:42 <novakane> And I think I only leave the explication for interface, event, requests because it's an inportant information IMO

15:44 <leon-p> well basically what I think we should have is documentation that allows someone who has never written Wayland code before to pickup, say, python and start scripting river without too much headache

15:44 <dnkl> I really miss the 'opacity' command... so much that I added something similar to foot - https://codeberg.org/dnkl/foot/pulls/676 - all my windows are terminals anyway :D

15:45 <leon-p> dnkl: sweet!

15:45 <leon-p> I feel like for opacity, client-side is definitely better than server-side

15:45 <dnkl> not sure if I'll merge it. But the change is pretty small, so maybe I will, even though it might be too "flashy" for foot...

15:46 <dnkl> leon-p: you definitely get more control over how/what to make translucent, and how much to change the opacity

15:47 <dnkl> leon-p: in foot's case, the patch is somewhat hacky, and incurs a quite noticeable performance impact for screen updates while the window is unfocused

15:47 <leon-p> dnkl: exactly. Server-side opacity has the massive disadvantage that content such as text or images will also be transparent

15:48 <dnkl> leon-p: right now that's what foot does too - everything is made transparent. That's how I like it in this case... but could probably be made optional, to e.g. just increase the "normal" background opacity, which is only applied to the default background color

15:57 <leon-p> so, other than floating state and the tags, is there any other river specific information clients should be able to get about toplevels?

16:00 <ifreund> fullscreen state?

16:00 <leon-p> already in zwlr-foreign-toplevel

16:01 <ifreund> dnkl: something similar to the opacity command may return to river in the (likely distant) future. I'm confident that removing it for now was the right move though especially as the wlroots scene graph API seems to be gaining traction

16:02 <ifreund> I assume foot needing to damage the whole frame every frame while unfocused is just to keep things simple and is not strictly necessary?

16:02 <ifreund> leon-p: right :)

16:09 <ifreund> leon-p: when we implement xdg-activation we'll probably want to add urgency

16:09 <ifreund> or actually that probably belongs in ext-toplevel-info

16:14 <dnkl> ifreund: yeah, opacity is applied in a final step, after everything else has been rendered, using an IN REVERSE operation with a "solid" transparent source "image".

16:14 <dnkl> that breaks the internal damage tracking

16:15 <dnkl> the alternative would have been to apply the alpha *while* rendering.

16:15 <dnkl> while that might work for regular cells, it's much more difficult with sixels

16:15 <dnkl> and probably not that easy with color glyphs either

16:39 <leon-p> hmm... I think we'll have a few problems extending the foreign toplevel protocol since the wlroots impl. is very self-contained

16:47 <ifreund> leon-p: changing wlroots to make it more extensible is very much an option

16:48 <ifreund> If we try to get ext-toplevel-info/ext-toplevel-management merged in wayland-protocols before merging river-toplevel we even need to write a new wlroots implementation

16:48 <leon-p> ifreund: had the same thought. Although I will have to look deeper into how protocols are supposed to work since I am not sure my idea is even doable

16:50 <leon-p> Basically what I want to do is have another global that sends events for floating state and tags with a foreign toplevel handle as parameter, since binding an additional object per toplevel handle has to many roundtrips for my taste

16:52 <ifreund> leon-p: why wouldn't the river-toplevel objects be server-side created alongside the ext-toplevel ones?

16:52 <ifreund> I don't see how a separate object would require more round-trips

16:54 <leon-p> ifreund: if they are advertised by a global then indeed there is no additional roundtrip. Clients would have to match the river-toplevel-handle with the foreign-toplevel-handle, but that is fine I guess.

16:54 <leon-p> only problem I see is keeping the events of both synchronous

16:55 <leon-p> If we have two different 'done' events fore both toplevel handles, clients tracking toplevels will not get atomic state updates

16:56 <ifreund> leon-p: the event creating the river-toplevel-handle could send the matching foreign-toplevel-handle as an argument

16:56 <ifreund> we should definitely only have a single done event, the one on the base object

17:00 <ifreund> dnkl: I see, that makes sense. That kind of full-buffer opacity is probably better done in the server tbh.

17:01 <ifreund> back when I used X11, I had my terminal's foreground color change on focus/unfocus to match my window border color

17:03 <dnkl> ifreund: agreed. I'll keep the PR open, but don't think I'll merge it. I'll try to keep it up to date, for those who'd like to use it until a server side implementation is in place

17:50 <novakane> so the river protocols wiki article v2, should be better https://paste.sr.ht/~novakane/15b5b04f9eed867af15465ef47390424fe4df108

17:50 <novakane> and the last version for today :P

17:53 <novakane> leon-p: ifreund should be more what you had in mind

18:20 <elshize> hey, I had river crash on me when I unplugged an external monitor from the laptop. full log: https://0x0.st/-Jpr.log (very long) just the errors at the end: https://0x0.st/-Jps.log and kanshi config: https://0x0.st/-Jpi.txt just letting you know, I'll try to dig deeper and maybe try to reproduce later tonight, will let you know...

18:30 <ifreund> elshize: were you running with commit 2f3fe501?

19:56 <Nulo> Hm, -release events are not called after releasing the modifier

19:56 <Nulo> Which makes sense but it is annoying

19:56 <Nulo> map normal Mod4 B spawn yambar

19:57 <Nulo> map -release normal Mod4 B spawn 'killall yambar'

19:57 <Nulo> When pressing on the Mod4 key and then the B, the bar appears, but if the Mod4 key is released before the B the bar doesn't disappear

20:19 <elshize> ifreund: yeah, compiled on "config: fix leak of default layout namespace" from yesterday

20:21 <elshize> ifreund: it's strange because I've been switching my display between two computers, and no problems usually

20:21 <elshize> e.g. I just did this to switch from my work laptop to personal, and no crash

20:22 <ifreund> sounds like a race :/

20:27 <ifreund> elshize: https://github.com/ifreund/river/issues/393#issuecomment-897129269

20:28 <ifreund> Nulo: the behavior you describe does sound nicer, and there's no technical reason river couldn't do that afaik. I'm not sure how complex it would be to implement though

20:29 <ifreund> I'm not planning on making such a change myself but if someone were to send a PR and the patch was reasonably simple I'd merge it

20:38 <elshize> ifreund: thanks. anything I could do to provide more info? do you think WAYLAND_DEBUG would be helpful?

20:40 <ifreund> elshize: if you can reproduce with a debug build or otherwise get a stack trace that would be helpful

20:41 <ifreund> I don't think WAYLAND_DEBUG will be useful here

20:42 <ifreund> there's a stack trace in that issue already, but It's not yet 100% clear the crash you hit is the same bug