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/
<ifreund> gbrlsnchs: indeed it will, should be much more secure. Master branch already does if you don't mind building from source
<gbrlsnchs> ifreund: that's awesome, thank you!
<tleydxdy[m]> time to rebase to master and create some blocker issues I guess 😀
<leon-p> the "New features" section of the 0.2.0 issue has an ominous "TODO river protocol enhancements" entry. I suppose that won't be part of this release then?
<tleydxdy[m]> how is the surface_box related to current.box? if at all
<tleydxdy[m]> I'm trying to fix the issue with gtk shadows and cursor warp
<ifreund> leon-p: oh, that's just a note for me to summarize the minor improvements that have happened since 0.1 for the changelog
<leon-p> ah, makes sense
<ifreund> tleydxdy[m]: surface_box is the wl_surface, current.box is the xdg shell geometry
<tleydxdy[m]> the only thing is their (0, 0) is at the same point on screen?
<ifreund> no
<tleydxdy[m]> so how can I figure out how big the window is including all the shadows
<ifreund> the 0,0 may be at different points
<tleydxdy[m]> basically what's the box that will have the view get focus if I mouse over it
<leon-p> I should probably create a test client that sets a weird geometry, because I think there are a few errors related to that
<leon-p> oh yeah, cursor moving with a window geometry != surface size is broken
<ifreund> tleydxdy[m]: View.current.box is the xdg shell geometry and the size we use to draw borders and arrange windows
<leon-p> and apparently moving via command and via cursor disagree on how it is broken
<leon-p> I'll see if I can have a patch ready for 0.2.0
<tleydxdy[m]> the problem is like this, I have a floating window, I move mouse towards it, mouse enters surface_box but outside current.box, window gets focus, mouse gets yanked to the window's center
<ifreund> leon-p: if you open an issue describing how exactly it's broken I'd be happy to fix that myself
<leon-p> sure
<leon-p> I wish we had something like firefox developer tools for Wayland, because I'd love to know which part of a view is a different surface
<ifreund> leon-p: you can use https://git.sr.ht/~kennylevinsen/wlhax to get some higher level introspection
<ifreund> tleydxdy[m]: it's not entering "surface_box" that's the problem but rather entering the input region defined by the client
<tleydxdy[m]> I see
<tleydxdy[m]> so input region can also be outside the current.box?
<tleydxdy[m]> that sounds very problematic
<ifreund> hey, I didn't write this part of the protocol
<ifreund> I'd suggest reading and understanding the relvant parts of wayland.xml regarding input regions and xdg-shell.xml regarding the "geometry"
<tleydxdy[m]> I do I get the bounding box of input_region then?
<ifreund> It might also be worth understanding why this client you use sets its shadows to be an input region, maybe this should just be a bug report for that client if there's not a good region
<ifreund> *reason
<tleydxdy[m]> * how
<ifreund> you shouldn't have to care about input regions, that's handled by Cursor.surfaceAt() internally
<tleydxdy[m]> I think someone in here said that it's because gtk stuff have thin borders so clicking on the shadows also works to resize it
<tleydxdy[m]> well, it causes problem with warp_on_focus+focus_follow_mouse
<tleydxdy[m]> so I have to disable warp_on_focus when the cursor is in input_region but outside view's box
<leon-p> ifreund: opened an issue
<ifreund> leon-p: thanks!
<ifreund> tleydxdy[m]: that doesn't sound like a very clean solution. Basing focus-follows-cursor off of the xdg shell geometry all the time might be reasonable
<ifreund> this isn't something I'm planning on blocking the release on though fwiw, I'm OK with telling people that those two options don't work great together
<leon-p> At least for SSD views it makes sense to restrict the input area to the geometry. For CSD I'd keep the status quo though.
<ifreund> All of this stuff will be so much easier once we move over to wlr_scene
<ifreund> I'll probably get started on that right after upgrading to zig 0.10 right after this release
<waleee> did sway adapt the scene-stuff in their new release?
<waleee> *adopt
<leon-p> nope, not yet
<leon-p> there is a PR, but it's not merged yet
<tleydxdy[m]> <ifreund> "tleydxdy: that doesn't sound..." <- yeah that also works, I'm not saying it's a blocker, just I'm working on it and get confused by surface_box
eShaev9z_ has joined #river
eShaev9z has quit [Ping timeout: 264 seconds]
alebastr has quit [Remote host closed the connection]
alebastr has joined #river
<ifreund> cool
waleee has quit [Ping timeout: 246 seconds]
talismanick has joined #river
dbuckley has quit [Ping timeout: 252 seconds]
ayushnix has quit [Changing host]
ayushnix has joined #river
dbuckley has joined #river
amyrat has joined #river
ayushnix has quit [Ping timeout: 260 seconds]
ayushnix has joined #river
ayushnix has joined #river
ayushnix has quit [Changing host]
amyrat has quit [Quit: WeeChat 3.7.1]
amyrat has joined #river
amyrat has quit [Quit: WeeChat 3.7.1]
alexherbo2 has joined #river
taupiqueur has joined #river
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
taupiqueur has quit [Ping timeout: 248 seconds]
taupiqueur has joined #river
alexherbo2 has quit [Remote host closed the connection]
taupiqueur has quit [Ping timeout: 252 seconds]
taupiqueur has joined #river
taupiqueur has quit [Ping timeout: 252 seconds]
taupiqueur has joined #river
<DZoidberg_> with firefox - my mouse cursor dissapears randomly, not with any other app. Is this a riverwm issue or not?
<tleydxdy[m]> cursor is managed by the app not river
<DZoidberg_> yes, but this only happens since my new keyboard - maybe its a gtk issue - thanks anyway
<scorpion2185[m]> how do I set an app to be opened as floating? using the title?
<leon-p> or the app-id
<scorpion2185[m]> how do I find it on wayland?
<scorpion2185[m]> what rule should I use ?
<leon-p> use a tool like lswt: https://git.sr.ht/~leon_plickat/lswt
<scorpion2185[m]> 0: ---- CopyQ com.github.hluk.copyq
<leon-p> the last field is the app-id, as explained in the man page. reading docs is a good habit.
<scorpion2185[m]> what doc tell me what river* command do that?
<leon-p> man riverctl, search for "filter"
<leon-p> all commands are documented in riverctl, as that is the only user-facing way to invoke them.
<scorpion2185[m]> float-filter-add or.copy-id ?
<scorpion2185[m]> what's the pattern in this case?
<scorpion2185[m]> float ?
<scorpion2185[m]> got it , thanks
<leon-p> riverctl float-filer-add app-id <the app-id>
<ifreund> leon-p: what patch do you have for snayk that reproduces https://github.com/riverwm/river/issues/748?
<leon-p> ifreund: https://paste.rs/pdh
<ifreund> thanks
<leon-p> could be that I am just holding the geometry setting wrong, but I have seen this same bahaviour from real world applications before
<ifreund> leon-p: moving/resizing behaves correctly for snayk with that patch here
<leon-p> hmm... I am on git head right now and I can reproduce
<ifreund> moving and resizing using the mouse right?
<leon-p> yeah
hspak60 has quit [Ping timeout: 272 seconds]
<leon-p> weird, anyway I would not call this a blocking release
<leon-p> s/release/issue
<ifreund> ah wait, I think I misunderstood what the expected behavior should be with this example
<leon-p> try moving the window up against the output edges. will work correcctly top and left, and wrong right and bottom
<ifreund> yep
<ifreund> it should be the same on all corners
<leon-p> another bug btw, we also subtract the border size from CSD windows in a layout
<ifreund> that one should be easy to find/fix at least
<leon-p> indeed
hspak60 has joined #river
<ifreund> leon-p: ok, fixed that one at least
<ifreund> getting back to the move/resize geometry issue now
<leon-p> oh, I also fixed it :D
<leon-p> I'll close the PR then
<ifreund> oh whoops, sorry bout that
<leon-p> nah, it's fine :P and funny
<ifreund> xD
waleee has joined #river
<DZoidberg_> I have mentioned this issue before - but I have more information to add. When I start Firefox (or any derivative) everything works fine but as soon as a resize it - my cursor dissapeares when in focus. I am just curious if this is a riverwm issue or if I should report this to firefox.
<leon-p> sounds like a firefox issue to me. does it say anything interesting in the logs?
<DZoidberg_> of river or firefox?
<leon-p> firefox
<DZoidberg_> ill check
<DZoidberg_> ok - I updated firefox - and it seems to work - also nothing interesting in the logs relating to river (or wayland)
<DZoidberg_> but it seems to be random so maybe I got lucky
<leon-p> I actually also had cursor problems a few FF versions ago
<leon-p> they were apparently fixed recently
<DZoidberg_> because of nixos, i sometimes forget to update some packages because not all updates are global
<DZoidberg_> anyway thanks
<DZoidberg_> one last question - is it possible to extend river? I want scratchpads, and I thought maybe I can extend river with a plugin or a seperate program which communicates over wayland which adds scratchpads
<leon-p> you can implement a scratchpad with the tag system, check the wiki, we have a short section on that
<DZoidberg_> ok
<DZoidberg_> thanks
<DZoidberg_> cool - it is really so simple - shows the power of the simple tag mask system of windows
<scorpion2185[m]> will `scratch_tag=$((1 << 20 ))` create it on the first free tag?
<ifreund> no, 1 << 20 means tag 20
<tleydxdy[m]> ifreund I opened a pr for the focus+warp issue, if you want to take a look
hspak605 has joined #river
<ifreund> cool
<scorpion2185[m]> I am new to scratchpads , do you send apps there to have them omnipresent?
hspak60 has quit [Ping timeout: 268 seconds]
hspak605 is now known as hspak60
<ifreund> leon-p: figured out why that snayk patch shows strange behavior. With that patch snayk does not respect the dimensions river sends in the xdg_toplevel configure event
<ifreund> with this patch for examplethings work as expected https://0x0.st/oRBZ.diff
hspak60 has quit [Ping timeout: 268 seconds]
hspak60 has joined #river
hspak609 has joined #river
hspak60 has quit [Ping timeout: 264 seconds]
hspak609 has quit [Ping timeout: 268 seconds]
hspak60 has joined #river
hspak60 has quit [Ping timeout: 260 seconds]
hspak600 has joined #river
hspak60 has joined #river
hspak600 has quit [Read error: Connection reset by peer]
hspak601 has joined #river
hspak60 has quit [Ping timeout: 272 seconds]
hspak601 is now known as hspak60
<leon-p> ifreund: I would still say there is a river bug here, since not respecting configure events is legal protocol wise
<leon-p> using the view dimensions we expect instead of the real view dimensions is a bit weird, IMO
<ifreund> leon-p: we need to decide where to stop the resize for example before we send the configure to the client
<ifreund> at this point in time we don't yet know if the client will respect our configure or not
<ifreund> we can probably handle clients that don't respect configures better by cropping ones that are too large and centering ones that are too small or something like that
<ifreund> and we could draw the borders based on what river expects/wants rather than what the client commits to make it more clear to the user that the client is misbehavint
<leon-p> hmm... that would mean that client's not correctly setting a min and max size are broken when resizing. That should not be that bad though.
<leon-p> ALso we'd have to draw borders over surface contents again.
<leon-p> either way, sounds like things easier done with the scene API
<leon-p> ok, so apparently you can break moving views with the cursor with a layout generator that responds slowly
<leon-p> I'll stop breaking things now
<ifreund> you're welcome to keep breaking things xD Good bug reports are quite useful as I obviously only use a pretty small subset of river's features these days
Szadek has quit [Quit: WeeChat 3.7.1]