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/
mattnite has joined #river
mattnite has quit [Client Quit]
mattnite has joined #river
waleee-cl has quit [Quit: Connection closed for inactivity]
mattnite has quit [Remote host closed the connection]
travankor has joined #river
jjanzic has quit [Read error: Connection reset by peer]
<leon-p> Hmmm... trying to get back into my code I wrote a few week ago is turning out to be a bit problematic.
<leon-p> Trying to get back into working on the layout PR, I am sure there was a reason I kept Layouts and LayoutDemands global instead of in per-output lists, but I can't remember why
<leon-p> And I think this approach will cause other problems
<leon-p> And it's turning into a bit of a pasta-fest already.
<leon-p> I think I have to redesign the implementation a bit
<leon-p> Technically we can get rid of one of the lists, actually. There can only ever be a single LayoutDemand per output, so there really is no need for a list.
<ifreund> leon-p: I should have time to take a detailed look later this afternoon/evening and see if I can't be of use
exception has joined #river
mmurd has quit [Ping timeout: 240 seconds]
mmurd has joined #river
ifreund has quit [Quit: WeeChat 3.0]
ifreund has joined #river
leon-p has quit [Ping timeout: 240 seconds]
travankor has quit [Ping timeout: 240 seconds]
waleee-cl has joined #river
leon-p has joined #river
leon-p has quit [Client Quit]
leon-p has joined #river
<leon-p> I think I've found a better design. Now layouts and layout_demands are no longer global but per-output. I think I initially had them global because a few revisions back LayoutV1 object were not output dependant. Working on that now.
<leon-p> pusedh the new design, if you'd still like a look.
exception has quit [Ping timeout: 240 seconds]
<ifreund> leon-p: yeah, having a list of layouts per-output is definitely the way to go
<ifreund> I added a couple of comments on the protocol that should actually make things easier to implement
<leon-p> ifreund: addressed most of your comments. But I don't get why the transaction (Root.zig, 266) should start a new layout demand.
<ifreund> if we start a transaction while one is already in progress we need to make a new layout demand as the old one is no longer vaild
<leon-p> I don
<leon-p> 't follow
<leon-p> A transaction does not invalidate the old one, does it?
<ifreund> it is kindof merged into the old one
<ifreund> that is we only send new configures if needed, otherwise use the configure from the previous transaction
<ifreund> for example if 2 views are closed in quick succession and the transaction started by closing the first view is not complete by the time we close the second view, we'd need a new layout_demand with one less view
<leon-p> closing the second view should trigger cancelling the first layout demand and starting a new, shouldn't it?
<leon-p> since output.arrangeView is called before root.startTransaction
<leon-p> And I was more thinking about the case of a layout demand happening, while something on a different output causes a transaction. In that closing the layout demand just to start an identical one makes no sense
<leon-p> s/that/that case/
<ifreund> ah I see, we'll stop calling startTransaction() manually after arrange views now and the layout manager or whatever will call it after it gets the response
<leon-p> yeah, I removed the startTransaction() in arrangeViews()
<ifreund> there was a startTransaction() there? ew
<leon-p> pretty sure there was. Although in the old model it made sense since everything was neatly in order.
<ifreund> hmm, I wonder if we should make transactions per-output instead of globabl
<leon-p> No idea
<ifreund> do we really care if a view disappears from one output a frame before it appears on the other?
<leon-p> Well, _I_ don't :D
<ifreund> are the frames of different monitors even in-sync enough to notice?
<leon-p> probably not. I can't imagine many people have setups with matching screens.
<leon-p> and even then, it is /physically/ impossible to get it perfect
<leon-p> even if the screens frefresh rate was locked to the AC freq
<leon-p> (which it usually isn't)
<ifreund> throw in different refresh rates for different monitors and I say it's a lost cause
<leon-p> in that case seeing every output as an independent atomic unit makes sense
<ifreund> I think that's the most sane way forward yeah
<leon-p> probably should put on github somewhere, so we remember
<ifreund> Implementing that would probably make your life easier for this PR, I should have time sunday
<leon-p> ¯\_(ツ)_/¯ I am fine either way. All I need to wrt transactions is blocking an output with LayoutDemand. Not complicated in either model.
<ifreund> true, though how you have it currently implemented does break atomicity across outputs already
<ifreund> (which is fine, since we just decided that's not worth it)
<leon-p> Independant output transaction probably also work better with your proposed ack_output_change thingy for the layer shell
<ifreund> yeah I was thinking that too
<leon-p> would enable us to have a "loading screen" while a new outputs layer shell widgets are setting themselves up, all while the otjher outputs could continue as normal.
<ifreund> I've done a lot of wlroots work in the past week so now would be a good time to try that while I'm in C mode
<leon-p> So we just solved the potential problems of "hangs" wrt that.
<ifreund> the idea would be to delay showing the first frame until the layer shell clients are ready
<ifreund> and yeah this change would mean that the other outputs dont wait for them
<leon-p> Hm... Shouldn't the compositor attach some sort of "Loading screen" buffer first? Even if it is just a black frame, probably still visiually better
<ifreund> not sure how the details work out, a black frame may be how its implemented
<ifreund> I've also fixed a lot of river bugs this week, but people keep sending in new ones :D
<leon-p> Also we need to consider that river is "special" since we /never/ display a surface on more than one outputs. On sway,f.e., you can move floating windows to be on multiple outputs at onve.
<leon-p> :D
<leon-p> anyway, regarding your last comment on the PR: I still think having the view indeces part of setViewDimensions() is the way to go. If we just allocate an array when the LayoutDemand is created (like what `calloc(view_amount, sizeof(struct LaoyutDemand))` in C would do), then there really is not much of complexity.
<ifreund> We need to send a protocol error when not all indexes are used as well
<leon-p> true
<ifreund> which is a lot easier when you can just check the length of your list
<leon-p> which is also just traversing it. So technically not /that/ different then iterating through an array
<ifreund> It's definitely doable, but I just don't see any significant benefit from the indexes and think erroring on the side of minimalism is a good approach with new protocols
<leon-p> I am just not happy with setViewDimension() having changing its behaviour wrt to practically opaque global value. Generally not what you want to see in APIs.
<leon-p> Although if we rename it to pushViewDimensions() it fits a bit better
<ifreund> indeed, push would be more clear
<leon-p> fine, I am renaming it.
<leon-p> cal
<leon-p> oh, wrong term
<ifreund> ifornia
<leon-p> nah, not the GNOME one, the PSOIX one :P
<leon-p> *POSIX
<leon-p> somehow I can't type today
<ifreund> heh. I'm off to bed and will probably be unavailable tomorrow, will take another look at where you're at with river-layout and see if I can be useful on sunday
<leon-p> thats fine. I'll try having it compile by then. Night!
danyspin97 has quit [Read error: Connection reset by peer]
danyspin97 has joined #river
danyspin97 has quit [Read error: Connection reset by peer]