ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor || https://github.com/riverwm/river || channel logs: https://libera.irclog.whitequark.org/river/
alexherbo2 has quit [Remote host closed the connection]
xtvl has quit [Ping timeout: 264 seconds]
xtvl has joined #river
xtvl has quit [Read error: Connection reset by peer]
xtvl has joined #river
eShaev9z_ has joined #river
eShaev9z has quit [Ping timeout: 255 seconds]
waleee has quit [Ping timeout: 255 seconds]
leopoldek has quit [Remote host closed the connection]
sewn has joined #river
<sewn> how do the slurping selecting clients work in river
<sewn> can't find info about it in the wiki or docs
<leon-p> sewn: you mean slurp? It just creates a fullscreen surface
ayushnix has quit [Read error: Connection reset by peer]
awesomerly has quit [Ping timeout: 268 seconds]
awesomerly has joined #river
<sewn> leon-p: I mean to select clients to screenshot
<leon-p> I am not sure I follow. Are you asking how the program 'slurp' works or asking how to take screenshots?
<LarstiQ> how to set up the portal?
<leon-p> LarstiQ: they are supposed to auto-launch (DBus socket activation), but you can also manually launch them
<leon-p> the executables are at /lib/xdg-desktop-portal, /lib/xdg-desktop-portal-wlrt, etc...
<LarstiQ> leon-p: yeah I mean, that would be my guess to what sewn is asking otherwise I don't get it
<leon-p> ah, screenshot portal integration. Didn't even cross my mind
<sewn> what no
<sewn> sway has a program to get the geometry of all windows, which can be passed to slurp to 'select' a window to screenshot with grim
<sewn> does river have this or not
<leon-p> ah, you are asking how slurp works, got it
<leon-p> no, river does not have that
<leon-p> on river, slurp merely allows you to draw a rectangle on your screen to select an area manually
<leon-p> (yes, automatically screenshotting individual windows would be neat, but doing so by getting the window geometry is a hack. We should instead just wait for a proper protocol for that. The correct way is to composite the window for the screenshot individually)
<sewn> so river doesnt
<sewn> wow thats
<sewn> disappointing
<leon-p> 🤷
<sewn> I love square characters
<LarstiQ> when would you use that `swaymsg -t get_tree` hack? That seems more cumbersome than just drawing a region. Clicking on a window would be nice but that's not what the example does
traidare has joined #river
Keeto has joined #river
Keeto has quit [Remote host closed the connection]
tiosgz has joined #river
<tiosgz> leon-p: fyi the input refactoring (0cae415a) breaks *_state fields ("riverctl ... events" etc). i assume those should be renamed by their commands, but idk
<tiosgz> ifreund: seems like clipping view to output (f0b0606e) breaks shadows (tested with a very obvious one: `window.csd decoration {box-shadow: 0 0 10px red;}`)
<tiosgz> not that i'd mind, but i don't think that's expected
<tiosgz> plus it (obviously) ignores layer-shell, not sure if that should be considered a bug
<leon-p> tiosgz: what do you mean by *_state fields?
<leon-p> I am not following
<tiosgz> i'm used to wlroots handling these offsets for us, but maybe i'm just ignorant?
<tiosgz> leon-p: `riverctl input something events enabled` and that kind of stuff. cos InputConfig has these as "event-state" etc
<leon-p> Ah
<leon-p> I see
<leon-p> those aren't options I use, so it didn't came to mind to test them
<leon-p> I think instead of renaming the commands, renaming the fields is better since it's not a breaking change
<tiosgz> that's what i thought too
<leon-p> luckily, thanks to the refactor, it's literally just renaming the fields :)
<tiosgz> plus perhaps adding a note that the names need to match?
<ifreund> tiosgz: what program do you use for the red shadow testing?
<ifreund> oh is that gtk CSS?
<tiosgz> ifreund: yeah, that's gtk css
<tiosgz> i used librewolf cos i know it's got a minimal size, but i think anything goes
<tiosgz> needs gtk to have csd, btw
<leon-p> pushed a quick PR fixing the names
<tiosgz> thanks :)
<ifreund> tiosgz: as for why the shifting is there, the clip region is interpreted by the scene graph as relative to the wlr_scene_subsurface_tree node
<ifreund> which is a child of the wlr_scene_xdg_surface node
<ifreund> the xdg_surface node applies the geometry offset for us, but we have to reverse it to get the clip region right
<tiosgz> ah. got it, thanks.
<ifreund> it's an API wart, I think the clip region should be interpreted as relative to the node we pass
<ifreund> As for why the shadows are broken, it the surface_clip.intersection(box, &output_box); call, we need to do our own logic there
<ifreund> actually, it's easier than that. I was just dumb :)
<ifreund> so, should be fixed
<ifreund> tiosgz: thanks for the bug reports :)
<tiosgz> np and thanks :)
<ifreund> as for ignoring layer shell, nobodies complained yet afaik but yeah we should probably clip them as well
<ifreund> should be more straightforward though since no borders :)
<ifreund> anyhow, I'm probably going to be offline the rest of today. Playing a concert this evening with my band ;)
<leon-p> have fun!
<leon-p> (and send bandcamp link, of course :] )
<leon-p> anyway, I thin rebasing against the input config refactor fixed the bug in the input config glob PR
<ifreund> leon-p: we don't have anything on bandcamp yet, someday :)
<ifreund> and nice, I'll have another look at that one tomorrow or over the weekend
<tiosgz> ifreund: oh. enjoy :)
<ifreund> thanks!
tiosgz has quit [Quit: tiosgz]
alexherbo2 has joined #river
flub has quit [Quit: WeeChat 3.8]
pkap has joined #river
<pkap> Hi, I think there may be a bug in the key handling when a mapping is executed. I am not sure what the intended behavior is though. When I press a key combination that is a mapping, e.g. Super K to focus another view, the Super key is send to the view I switched to.
<pkap> Instead of beeing "used up" by the mapping.
pkap has quit [Quit: Client closed]
pkap has joined #river
<pkap> I noticed this when with an RDP Windows session because the start menu pops up all the time when switching views or tags.
<pkap> Is this the intended behavior or is it a bug?
<pkap> I saw that there where some commits recently that could be related to this...
pkap has quit [Quit: Client closed]
pkap has joined #river
<leon-p> That is intended behaviour
<leon-p> When you press Super+K, river first sees the Super key press event, then the K key press event. When the super key press event is received, river has no idea what will come after
<leon-p> and since making use of the super-key on the application level is valid, it gets send along
<leon-p> The k key will not, because that is a keybind
<pkap> Hm I see. I suppose I have to live with this then.
<pkap> But not a big deal just a minor annoyance.
<pkap> I have another small thing. When switching off and on the monitor, e.g. with wlr-randr, the stack of views is reversed.
<pkap> This also happens when I unplug one monitor, the views are stacked into the new output in the opposite order.
<pkap> I suppose this is a bug?
<pkap> It's not very important though....
alexherbo2 has quit [Remote host closed the connection]
traidare has quit [Ping timeout: 260 seconds]
<adamcstephens> I'm confused about tag rules. When I set `riverctl rule-add -app-id WebCord tags 6`, it gets a rule of `* WebCord 110`, and then opens on tag 2....
<adamcstephens> I take it 110 is the binary representation, but that doesn't explain why it's not launching on tag 6 as I'd expect
<ifreund> adamcstephens: you want (1 << 5) or 100000 in binary
<ifreund> "tag 1" is (1 << 0), "2" is (1 << 1), etc.
<ifreund> your rule says to start it on tags 2 and 3 currently
<ifreund> (yes, bitmasks are not good UX)
<adamcstephens> yeah that doesn't clarify how i actually set that using the cli
<adamcstephens> :)
<adamcstephens> riverctl rule-add -app-id WebCord tags 100000 ... yields an action of 11000011010100000
<adamcstephens> ok, this works in bash: riverctl rule-add -app-id WebCord tags $((2#100000))
<adamcstephens> may be worth a ux improvement there, or at least some examples in the man page
Axenntio has joined #river
Axenntio has quit [Remote host closed the connection]
traidare has joined #river
leopoldek has joined #river
pkap has quit [Ping timeout: 250 seconds]
<The_Buhs> adamcstephens I just took it based on all the various keybinds in the default config that relate to tags
<The_Buhs> `sh` or `bash` would be nice.
leopoldek has quit [Remote host closed the connection]
<adamcstephens> or support decimal which is what we humans are trained to think in by default :)
<adamcstephens> looking at the other tag section would have been helpful for sure. i wasn't even looking at my config at all though 🤦‍♂️
<LarstiQ> the thing with decimal is I guess wanting to set more than one tag?
ayushnix has joined #river
traidare has quit [Ping timeout: 268 seconds]
<leon-p> this is a case of the implementation leaking into the UI/UX, possible alternatives would be to support syntax like 0b0001001 or maybe tag-index:1,4
<leon-p> not sure it's really worth it though. You touch this once in your config and then never again
ccha has quit [Quit: WeeChat 4.2.1]
ccha has joined #river
leopoldek has joined #river
Guest82 has joined #river
Guest82 has quit [Quit: Client closed]
coding-agent has joined #river
<coding-agent> guys
<coding-agent> I want to do a simple app to change wallpaper
<coding-agent> I have been reading the wayland-book
<coding-agent> but to use zig-wayland because can't get completions and go to definition of of the lib to check code
<coding-agent> any advised?
<coding-agent> *advises?
waleee has joined #river
coding-agent has quit [Quit: Client closed]
coding-agent has joined #river
coding-agent has quit [Client Quit]
traidare has joined #river
traidare has quit [Ping timeout: 268 seconds]
awesomerly has quit [Read error: Connection reset by peer]
awesomerly has joined #river