wlroots 0.16.0

[m-col]

Most things listed in #108 are complete.

Using Qtile to test everything, I'm struggling to get Internal windows working, which mostly pertains to wlr_buffers, wlr_textures, and wlr_allocator. Still fiddling with these.

Then lastly tinywl will need updating.

[m-col]

Looks like I got the git history messed up at some point, likely starting this branch from a non-main local branch. Ignore the first 10 commits.

[m-col]

Marked ready for review as I've covered most ground for the update and have qtile working with these changes (qtile/qtile#3985). While my questions above still stand (as I still sometimes get confused as to which objects need weafreffing), the half-guesses I've made WRT weakrefs do work, so my above questions could be ignored if that expediates review/merge etc.

As for failed github actions, it seems 2 of them pertain to issues setting up wlroots master, and the protocol header test, which I haven't touched - could that be unrelated?

[flacjacket]

Awesome! I'll check this out, but we should also be able to just merge and iterate on it until it gets to a working state. The protocols headers test probably just needs the protocol include files to be regenerated since the wlroots headers were updated (with python ./check_headers.py --generate), but I see that is also failing on master.

[m-col]

Pushed a couple more commits. Most are minor changes and fixes. The more interesting one is 771e705 which changes out setting the .data member on structs works. The trouble I was running into was doing something like this:

self.tree.node.data = some_object.some_data

because of how we wrap objects, the objects created by some_object.some_data and self.tree.node are both ephemeral, so keeping the new handle for the former as an attribute on the latter didn't really work. Using a weakkeydict can also be difficult in this situation, because what persists as a key? The two objects and the handle are all ripe for garbage collection after the property setter returns. So as a solution for when this situation happens, I've updated the setter so that one can pass a pre-made handle. This way I can create, say, a handle for each window in the compositor, then pass that handle around to set the data, and the window keeps the handle alive. If instead a user wants to pass in a python object and have the handle made for them, the handle is kept alive in the weakkeydict for as long as the python object is alive, which they would then be responsible for.

[m-col]

Nvm above Q about weakrefs, I think I got it sorted now.

This PR is ready to go. I think the failures are unrelated.

[flacjacket]

Great thanks! I'll try to get this checked out ASAP.

…

On Thu, Feb 16, 2023, 17:15 Matt Colligan ***@***.***> wrote: Nvm above Q about weakrefs, I think I got it sorted now. This PR is ready to go. I *think* the failures are unrelated. — Reply to this email directly, view it on GitHub <#109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFGJBJKTZN6UWOBBTVL6M3WX2RGLANCNFSM6AAAAAAR6SMQ34> . You are receiving this because you commented.Message ID: ***@***.***>

[flacjacket]

Looks good! Lets get this in!