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]