<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>
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>
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
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