06:08 <Nosrep> NickH: I assume blurring of inactive windows

06:08 <Nosrep> no that's not what i meant

06:08 <Nosrep> they meant

06:08 <Nosrep> s/inactive/transparent

07:28 <leon-p> realistically the best chance for that appearing in river is if that blur region protocol happens and get's a wlroots impl., because then we'd likely don't actually have to do anything ourselves

07:30 <leon-p> also it's basically impossible to do without a region correctly anyway, especially when considering CSD and surfaces that are larger than the toplevel dimensions

08:44 <NickH> So people want text in non-focussed windows illegible? Seems like a poor use of screen realestate.

08:44 <NickH> But I guess there is some usecase that just doesn't occur to me.

09:29 <tiosgz> NickH: it's a way to make content easier to read even with transparency. imagine you got a wallpaper and open a terminal with 50% background transparency

09:30 <tiosgz> the text is illegible, but it may be with the wallpaper blurred. unixporn used to be full of blur

09:30 <tiosgz> for examble take last screen in this one https://old.reddit.com/r/unixporn/comments/15j77id/awesomewm_feels_good_to_be_back/

09:31 <tiosgz> (though iiuc that's just firefox with its opacity reduced everywhere, not only background surfaces)

14:18 <tiosgz> ugh, finally found the cause of #830 (output switching lock-out)

14:18 <tiosgz> /facepalm

14:18 <tiosgz> https://codeberg.org/tiosgz/river/commit/a7ed10663cdb827dbf7ab95923533b14fa8fef26

17:40 <Guest97> hello. I need a help here, this might be a noob question. but how you config river to open external link in firefox new tab (I have configured firefox settings, on sway it works just find)

17:40 <Guest97> example: https://postimg.cc/gx7TC4ss

20:25 <Guest52> Is there a way to get an ID or something similar of the currently focused window? My main motivation is that I want to be able to change the size of the currently-focused window in my layout generator. I thought it would maybe be possible with the status protocol, but that only gives you the title of the window, which I can't use to correlate to a

20:25 <Guest52> view in the layout protocol.

20:35 <tiosgz> Guest97: (if you read the log) i think you're missing dbus, in which case you should do the same you do for sway. that usually means dbus-run-session or something similar

20:36 <tiosgz> Guest52: that's not how layout generators are meant to work in river :P

20:37 <tiosgz> the 'zoom' command may be of interest to you (i rediscovered it for myself recently)

20:37 <tiosgz> or if you share more info, someone may be able to help you achieve your goal

20:39 <Guest52> I'm aware of the zoom command. I'm trying to emulate the cfacts patch for dwm, i.e. allow windows on the stack to grow in height. So instead of uniformly dividing the height of the stack amongst all windows, I'd like to allocate more space to some windows and less to others.

20:40 <Guest52> So if a window on the stack is currently focused, I'd like to be able to send a command to the layout generator which tells it to allocate a bit more space for the currently-focused window.

20:40 <Guest52> But for that to work, I'd need to (1) get the currently focused window, and (2) correlate that to the index of the window in the layout demand.

20:41 <Guest52> Which I don't think I can currently do. But that's more or less what I'm asking, if such a thing is possible or not.

20:49 <Guest97> tiosgz: hey that's work. thank you for your help!

20:52 <novakane> Guest52: maybe with the wlr-foreign-toplevel-management protocol, where you can have a state of the view

20:57 <novakane> although I don't think you can use it in a layout generator after that

21:38 <leon-p> Guest52: I would be surprised if you could reliably emulate cfacts. There are currently no unique window ids and even if there were, there would be no way to associate them to a position in the window stack

21:44 <Guest52> leon-p: Are there any plans to add window IDs to the layout protocol? I imagine there are other uses cases where it would be useful.

21:46 <Guest52> The way I see it: I can get the focused window through the status protocol. If that included the window ID, and the layout protocol did as well, it would be trivial to correlate them

21:48 <leon-p> Guest52: there are plans for unique window IDs (I have an open PR for that floating around)

21:48 <leon-p> but not to include that with the layout mechanism

21:49 <leon-p> long-term the layout protocol will be replaced with something more powerful, so that basically all window management can be outsourced to the layout generator, but right now we'll keep things simple

21:51 <leon-p> we actually used to send title and app-id to the layout-generator, but we removed that for some reason, can't remember

21:54 <Guest52> oh, I see. Thanks. I'll just hack something together then for my own use.

22:57 <NickH> tiosgz: nice that you've found a fix for but 830. Are you making a PR?