<leon-p>
ifreund: have you had some time to think about how to respond to a foreign toplevel activation request? Just pinging because that is something I'd like to have as well.
<ifreund>
leon-p: no, not yet. I've been prioritizing stuff that blocks river 0.1.0 and the distribution thereof
<leon-p>
ifreund: I see. Anything I can help with?
tmpm697 has quit [Remote host closed the connection]
tmpm697 has joined #river
<ifreund>
leon-p: any investigation/fixes for the open bugs is always much appreciated
<ifreund>
I want to fix every bug I can before 0.1.0
<ifreund>
leon-p: were you able to reproduce that race condition with mako? testing my PR for that would be helpful
<leon-p>
I'll try running your PR branch for a bit
<ifreund>
(the race condition is a new notification happening between mako's initial commit and the configure we send
<ifreund>
at least if I understand things correctly, which I'm pretty sure I do at this point
<ifreund>
thanks
leon-p has quit [Quit: leaving]
leon-p has joined #river
<ifreund>
leon-p: so with regards to #331, I don't think a command to toggle csd for a view sounds useful aside from testing. It's not really a piece of config that people want to change dynamically
<ifreund>
and if we don't have such a command, then I think the csd filter should definitely apply to existing views as well when modified
<leon-p>
ifreund: I think I found another bug: The cursor is only updated when the pointer is moved. So even if the view under the pointer changes a new cursor image is only used when the pointer is moved.
<ifreund>
I think I've seen that before but it didn't bother me enough to do anything :D
<ifreund>
would you like to open an issue for that?
<leon-p>
RE: CSD filter. If we don't want to add a command to toggle it, then I think the filter modifying existing views works fine. We just needs to document which filter modifies existing views and which does not.
<leon-p>
RE cursor: I'll open an issue, although I already have a suspicion
<leon-p>
fwiw mako still shows notifications, btw. I have been running a few notification heavy programs the last few minutes and everything still works. If this does not change in, say, an hour, I think this bug is fixed.
<ifreund>
leon-p: I think the docs for the two filters are already coherent with the behavior of acting on existing views for the csd filters and only applying to new views for the float filter
<ifreund>
they could certainly be made more explicit though to prevent confusion
<leon-p>
ifreund: I'll work on making the csd-filter apply to existing views as well then
<novakane>
for the cursors I think it's because of `output.wlr_output.renderSoftwareCursors(null)`
<leon-p>
novakane: unlikely, that is just a fallback for when the video card has no cursor plane
<novakane>
should be something llike renderSoftwareCursors(damage)` not sur if we can do this before full damage tracking
<novakane>
leon-p: hmm ok, sway do it with damage though
<leon-p>
novakane: not attaching damage to that may be a different bug, but not this one I think. On setups with hardware cursors, that function is a no-op.
<leon-p>
and pretty much any common hardware should have hardware cursors
<novakane>
allright, it was just someting I remember looking at damage tracking
<leon-p>
ifreund: currently there is no link betweeen Decoration and View, as far as I am aware. But for the CSD filters to apply to existing views it would be helpful. Should I either a) add a new ?*Decoration member to XdgToplevel or b) add a global list of all Decoration objects to DecorationManager ?
<leon-p>
both would work
<leon-p>
btw, mako still shows notification, so I think your patch fixed that bug
<ifreund>
leon-p: I'd prefer a list of decoration objects in the decoration manager I think
<ifreund>
thanks for testing mako, I'll just merge that now
<leon-p>
nice, that means I can turn off those annoying IRC notifications now :D
<leon-p>
updating decoration mode on filter add/remove almost works now. Only problem is that clients updates lag behind by a transaction or two.
<ifreund>
I don't think I really care about that tbh
<leon-p>
It is a bit annoying because you have to initiate that transaction manually, f.e. by changing focus
<leon-p>
makes me think I missed something
<leon-p>
btw, for now I have just put it onto the filter-remove branch. If you want to go through with a global reset command I can rebase it against that as well.
<ifreund>
the global reset thing doesn't need to happen on that branch
<leon-p>
I know, just letting you know where the patch is
<leon-p>
Actually, only foot seems to have that issue, other things respond fine to changing between CSD and SSD
<ifreund>
cool, I'll try and take a look at what's happening with the transactions there when I have a minute
<ifreund>
hmm interesting
<ifreund>
perhaps foot waits until the next time it renders for some other reason to respond to the change
<dnkl>
ifreund: leon-p: looks like a bug, yeah. It doesn't re-render on SSD <--> CSD changes.
waleee has joined #river
<leon-p>
ifreund: the cursor warp PR now also adds a config option for that feature
novakane has quit [Quit: WeeChat 3.2]
yyp has quit [Ping timeout: 265 seconds]
novakane has joined #river
<novakane>
oh someone made zig bindings for fcft, I just started to do it some days ago and didn't have time to finish
<novakane>
no excuses to be too lazy to play with fonts in zig now :P
<novakane>
yeah I was just reading the code, looks like he fell in love with river too :D
<leon-p>
dnkl: give me a few hours, I am a bit distracted rn
<dnkl>
leon-p: no rush :)
tmpm697 has quit [Quit: Lost terminal]
yyp has quit [Remote host closed the connection]
novakane has quit [Quit: WeeChat 3.2]
<leon-p>
dnkl: that PR does not fix the issue
<leon-p>
fwiw, the issue is not foot not rendering after a decoration mode change, but rather foot not resizing immediately.
<ifreund>
oh, you mean not making the terminal area of the surface smaller inorder to make space for the decorations while maintaining the same surface size?
<leon-p>
yes
<leon-p>
although I suspect foot uses a subsurface for the decoration
<ifreund>
yeah, I meant the same xdg_surface geometry
<leon-p>
although it is not unlikely I forgot something
<leon-p>
other clients I tested worked, but I don't know their surface structure. If they use a single surface, whether CSD or SSD, they'll keep their size and not show such a bug, should it exist
<ifreund>
a WAYLAND_DEBUG=1 log of foot doing this would show exactly what's happening
<leon-p>
huh, I think I forgot to send the xdg_surface.configure event
<leon-p>
actually scratch that, that is only needed for the request, not the event
<leon-p>
and wlroots sends it automatically anyway
<ifreund>
leon-p: the compositor does need to send xdg_surface.configure when setting the decoration mode, and wlroots handles this for us
<ifreund>
as you seem to have discovered
<leon-p>
actually, the protocol is not entirely clear on this, at least to me. When the client sets its decoration mode, a xdg_surface.configure event is guarenteed, but when the server sets it, the wording is vague and could be interpreted either way.
<ifreund>
If foot is changing it's xdg surface geometry away from the geometry last requested by the compositor in response to this event, then I'd say that's a foot bug
<leon-p>
I certainly wonder why foot uses 8 subsurfaces for the CSD. At least that many get torn down when it changes back to SSD.
<ifreund>
leon-p: it says see xdg_surface.configure for details, xdg_surface.configure is pretty clear about how this works
<ifreund>
also where else would the client get a serial to ack with
<leon-p>
yes it is implied, but I think not very clearly.
waleee has quit [Ping timeout: 264 seconds]
<leon-p>
"see xdg_surface.configure for details" does not equal "an xdg_surface.configure event must always be send after this event"
<ifreund>
I agree that the xdg-decoration protocol could be more explicit, but I think it's pretty clear that thats way things are intended to work
<leon-p>
considering I learned english binge watching british TV, I won't argue with you over the exact meaning of english text :D
<ifreund>
which is the exact same way xdg_toplevel.configure and xdg_popup.configure work
<ifreund>
oh I agree that the protocol is not as explicit as it probably should be, I'm talking mostly about the intent here
<leon-p>
anyway, I worked on the things you found in your review of the spacial output focusing PR. If you don't find anything else, it should be ready.
<ifreund>
sweet, thanks
<ifreund>
I think I'm done programming for today though, I'll give it a look and probably merge tomorrow