Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add method for importing external proxies #731

Merged
merged 7 commits into from
Jun 18, 2024

Conversation

chrisduerr
Copy link
Contributor

See #730.

@chrisduerr chrisduerr requested a review from ids1024 May 30, 2024 00:51
@chrisduerr
Copy link
Contributor Author

chrisduerr commented May 30, 2024

I've tested this against my browser and it seems to work, I just have to define my own ObjectData. I'd assume this could potentially be solved by further integration (?), though hooking it up myself is fine too.

One thing I've noticed is that with neither Catacomb nor Sway I'm getting any ObjectData::destroyed calls, however I am getting ObjectData::event calls. My browser still crashes after ~1000 WlBuffers which are never destroyed. Am I missing something from this PR? I would have assumed this would mean I could handle the destroy calls.

@chrisduerr
Copy link
Contributor Author

One thing I've noticed is that with neither Catacomb nor Sway I'm getting any ObjectData::destroyed calls

Obviously they're not, it's up to me to destroy the WlBuffer. I confused myself here and they are indeed getting release events.

Copy link
Member

@elinorbgr elinorbgr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also needs a changelog entry.

wayland-backend/src/sys/client_impl/mod.rs Outdated Show resolved Hide resolved
wayland-backend/src/sys/client_impl/mod.rs Outdated Show resolved Hide resolved
Comment on lines 103 to 104
/// There must never be more than one party managing an object. This is only
/// safe to call when a third party is transferring ownership of the proxy.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// There must never be more than one party managing an object. This is only
/// safe to call when a third party is transferring ownership of the proxy.
/// There must never be more than one party managing an object. This is only
/// safe to call when a third party gave you ownership of an uninitialized proxy.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, this should have a note regarding the fact that the interface is not checked, and while giving a wrong interface should not cause memory unsafety, it will definitely cause protocol errors.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly is an "uninitialized" proxy? Doesn't it have to be initialized to exist? I'm using this for a WlBuffer that already has a buffer attached and everything, this suggestion makes it sound like I'm using my own API wrong…

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm not sure what would be the best wording for that. What I mean is a proxy which has not yet been assigned a "listener" (using libwayland vocabulary).

Copy link
Contributor Author

@chrisduerr chrisduerr Jun 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unmanaged might be better than uninitialized?

It's vague enough to not have a precise meaning, so people think for themselves, but it gives a general idea as to what kind of things shouldn't have been performed on the proxy?

@chrisduerr chrisduerr requested a review from elinorbgr June 3, 2024 11:45
@chrisduerr
Copy link
Contributor Author

CI failures are unrelated to my changes, seems like freedesktop issues.

@elinorbgr
Copy link
Member

Yes, it seems like freedesktop's gitlab is currently in maintenance.

@chrisduerr
Copy link
Contributor Author

Freedesktop should be back if you want to restart CI.

@elinorbgr elinorbgr merged commit 41bab57 into Smithay:master Jun 18, 2024
14 checks passed
@chrisduerr chrisduerr deleted the import_external branch June 18, 2024 15:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants