ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/
jjanzic has quit [Ping timeout: 256 seconds]
travankor has joined #river
travankor has quit [Ping timeout: 240 seconds]
travankor has joined #river
travankor has quit [Ping timeout: 240 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
travankor has joined #river
travankor has quit [Ping timeout: 240 seconds]
ifreund1 has joined #river
ifreund has quit [Ping timeout: 256 seconds]
ifreund1 is now known as ifreund
<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.
<ifreund> Nice, I'm also quite happy with where the protocol has ended up
<ifreund> zig-wayland too, though I do wonder if things could be made even better by ditching libwayland
maddo has joined #river
<maddo> \o
maddo has quit [Remote host closed the connection]
maddo has joined #river
<ifreund> o7
<ifreund> leon-p: can you still reproduce this issue on master? https://github.com/ifreund/river/issues/109
waleee-cl has joined #river
jjanzic has joined #river
<leon-p> ifreund: yes, still reproducable
<leon-p> but I am no longer sure its a bug
<leon-p> because when clicking on GTK shadows, the toplevel request a pointer-resize
<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"
<leon-p> Or in other words, while GTK handles this case, I am not sure it is a case that should ever happen
<leon-p> Maybe we should think about not sending input events outside the window bounds
<leon-p> just tested and sway does not send input events to the client when clicking on the gtk shadow
<leon-p> Although we should not take what Sway does as gospel, they made mistakes before
<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™
<ifreund> I'm guessing they do what we currently do
<ifreund> are you gonna install gnome or am I? :P
<leon-p> I had it installed last month...
<leon-p> Luckily I am currently with my family. My sisters laptop runs with it
<leon-p> maybe I can "borrow" the laptop
<ifreund> nice
<ifreund> I think the current behavior we have feels pretty reasonable tbh if people want to resize views by grabbing an edge
<leon-p> yeah I think so as well. CSD clients who don't want this behaviour can just set their input region I think
<ifreund> now currently we only do resizing from the bottom right corner "properly" but that's a different issue
<ifreund> I've almost got all the bugs I can reproduce fixed!
<leon-p> Nice!
<ifreund> xwayland thing next
<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
<ifreund> yeah totally agree
<leon-p> speaking of, I think the roadmap may need to be updated at some point
<ifreund> I plan on just closing the issue when I release 0.1.0
<ifreund> milestones + individual issues makes more sense at this stage IMO
<leon-p> anyway, I'll close the #109
<ifreund> cool
<ifreund> I should probably go write implementations for my wayland-protocols PRs
<leon-p> I think #12, #24, #26, #73, #81, #150 can also be closed TBH
<leon-p> what protocols are you working on?
<leon-p> And have you MR'd yet? I have not received the email notify thingy
<ifreund> Basically I want foreign-toplevel-management upstreamed and split
<leon-p> ah, I saw that discussion
<leon-p> those will be nice to have
<leon-p> although I fear the freedesktop process is way to slow for that to happen in the forseable future
<ifreund> probably, but better to start the ball rolling now
<ifreund> the ball is still in my court too, I need implementations before they are valid to merge
<ifreund> Maybe I should finally implemnent that layer-shell fix first though
<leon-p> i don't know. I am slowly thinking the layer shell is beyond fixing
<ifreund> did you see my output-ack thing? In what other way is it currently broken?
<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
<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
<ifreund> yeah a lot of more complex stuff relys on transparent areas
<ifreund> mako's notifications are all on one surface iirc
<leon-p> and basically all implementation are broken
<ifreund> I think it'd be hard to improve without giving more control/power to the clients
<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
<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
<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.
<leon-p> I can then rotate the icons on my launcher without flickering
<ifreund> also good for lockscreens/bars/backrounds when hotplugging monitors
<ifreund> but yeah I didn't event think about the mobile use-case
<leon-p> yeah I think if we have such output-acking consistently for all relevant protocols, we could even do it smoother than android
<leon-p> btw, I think foreign-toplevel-info-v1 is missing an empty line after 41
<ifreund> thanks
exception has quit [Quit: rip internet]
exception has joined #river
<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™
<ifreund> cool, thanks for testing
<ifreund> I don't know how I feel about agreeing with mutter on something over sway though :D
<leon-p> :D
<leon-p> as long as river doesn't do DBUS, we're fine
<ifreund> ugh, well I know why moving views is buggy on xwayland
<ifreund> I forgot that X is busted and you have to tell clients when you move them
<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...
<leon-p> s/there/therefore/g
exception has quit [Ping timeout: 240 seconds]
ifreund1 has joined #river
ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #river
ifreund1 has quit [Ping timeout: 240 seconds]
cbix has quit [Excess Flood]
cbix has joined #river
maddo has quit [Remote host closed the connection]
waleee-cl has quit [Ping timeout: 260 seconds]
dch has quit [Ping timeout: 260 seconds]
dch has joined #river
waleee-cl has joined #river
travankor has joined #river
travankor has quit [Ping timeout: 240 seconds]