12:46 <leon-p> did some work on rivertile today and am pretty convinced on the protocols design now. And on zig-wayland. Having four river_layout objects for the same layout but with different main direction works even better than expected.

12:52 <ifreund> Nice, I'm also quite happy with where the protocol has ended up

12:53 <ifreund> zig-wayland too, though I do wonder if things could be made even better by ditching libwayland

14:55 <maddo> \o

14:57 <ifreund> o7

15:23 <ifreund> leon-p: can you still reproduce this issue on master? https://github.com/ifreund/river/issues/109

17:23 <leon-p> ifreund: yes, still reproducable

17:24 <leon-p> but I am no longer sure its a bug

17:24 <leon-p> because when clicking on GTK shadows, the toplevel request a pointer-resize

17:25 <leon-p> TBH I find it a bit confusing that the client can even receive input events when it clearly marks that part of the surface as not belong to the "window"

17:26 <leon-p> Or in other words, while GTK handles this case, I am not sure it is a case that should ever happen

17:26 <leon-p> Maybe we should think about not sending input events outside the window bounds

17:28 <leon-p> just tested and sway does not send input events to the client when clicking on the gtk shadow

17:29 <leon-p> Although we should not take what Sway does as gospel, they made mistakes before

17:29 <leon-p> I think we should see what GNOME does. They are the drivers behind CSD, so I'll consider how they do it the Right Way™

17:34 <ifreund> I'm guessing they do what we currently do

17:34 <ifreund> are you gonna install gnome or am I? :P

17:35 <leon-p> I had it installed last month...

17:35 <leon-p> Luckily I am currently with my family. My sisters laptop runs with it

17:35 <leon-p> maybe I can "borrow" the laptop

17:36 <ifreund> nice

17:36 <ifreund> I think the current behavior we have feels pretty reasonable tbh if people want to resize views by grabbing an edge

17:37 <leon-p> yeah I think so as well. CSD clients who don't want this behaviour can just set their input region I think

17:37 <ifreund> now currently we only do resizing from the bottom right corner "properly" but that's a different issue

17:37 <ifreund> I've almost got all the bugs I can reproduce fixed!

17:38 <leon-p> Nice!

17:38 <ifreund> xwayland thing next

17:38 <leon-p> Re: resizing from all corners and edges: Probably nice, but I think thats something for later, when we really run out of ideas

17:39 <ifreund> yeah totally agree

17:39 <leon-p> speaking of, I think the roadmap may need to be updated at some point

17:40 <ifreund> I plan on just closing the issue when I release 0.1.0

17:40 <ifreund> milestones + individual issues makes more sense at this stage IMO

17:41 <leon-p> anyway, I'll close the #109

17:42 <ifreund> cool

17:43 <ifreund> I should probably go write implementations for my wayland-protocols PRs

17:44 <leon-p> I think #12, #24, #26, #73, #81, #150 can also be closed TBH

17:44 <leon-p> what protocols are you working on?

17:45 <leon-p> And have you MR'd yet? I have not received the email notify thingy

17:45 <ifreund> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/59 and 60

17:45 <ifreund> Basically I want foreign-toplevel-management upstreamed and split

17:46 <leon-p> ah, I saw that discussion

17:46 <leon-p> those will be nice to have

17:47 <leon-p> although I fear the freedesktop process is way to slow for that to happen in the forseable future

17:48 <ifreund> probably, but better to start the ball rolling now

17:48 <ifreund> the ball is still in my court too, I need implementations before they are valid to merge

17:49 <ifreund> Maybe I should finally implemnent that layer-shell fix first though

17:50 <leon-p> i don't know. I am slowly thinking the layer shell is beyond fixing

17:50 <ifreund> did you see my output-ack thing? In what other way is it currently broken?

17:50 <leon-p> I am sure drew only though about the most basic status bars and background images when designing it. Every more aadvanced is painful

17:52 <leon-p> for example hiding your bar: There is no standardized way to know when to hide and when to show. Either always hide or use some non-standard compositor dependant protocols for auto-hide. And you can't actually hide. You need a transparent surface to catch the pointer event to unhide

17:53 <ifreund> yeah a lot of more complex stuff relys on transparent areas

17:53 <ifreund> mako's notifications are all on one surface iirc

17:53 <leon-p> and basically all implementation are broken

17:54 <ifreund> I think it'd be hard to improve without giving more control/power to the clients

17:54 <leon-p> imagine you have two small layer surfaces on the bottom. They would fit side by side perfectly. But all compositors display them above each other

17:55 <leon-p> or having a bar at the top and a launcher thing at the left. One will always move the other if you use exclusive zone, despite them fitting already

17:56 <leon-p> although the output-ack thing will be insanely great for mobile devices: I am specifically thinking about a phone where the screen rotates constantly.

17:56 <leon-p> I can then rotate the icons on my launcher without flickering

18:00 <ifreund> also good for lockscreens/bars/backrounds when hotplugging monitors

18:00 <ifreund> but yeah I didn't event think about the mobile use-case

18:02 <leon-p> yeah I think if we have such output-acking consistently for all relevant protocols, we could even do it smoother than android

18:03 <leon-p> btw, I think foreign-toplevel-info-v1 is missing an empty line after 41

18:07 <ifreund> thanks

19:17 <leon-p> just tested GNOME; They do it like we currently do it: send clients input events outside of window bounds. So we are already doing it the GNOME-approved™ Right Way™

19:20 <ifreund> cool, thanks for testing

19:20 <ifreund> I don't know how I feel about agreeing with mutter on something over sway though :D

19:22 <leon-p> :D

19:22 <leon-p> as long as river doesn't do DBUS, we're fine

19:29 <ifreund> ugh, well I know why moving views is buggy on xwayland

19:30 <ifreund> I forgot that X is busted and you have to tell clients when you move them

19:40 <leon-p> interestingly such stories never make it into blog posts, while hundreds of "wayland doesn't do $USELESS_FEATURE and there is bad" somehow do...

19:40 <leon-p> s/there/therefore/g