client-toolkit/toplevel-info: Work with only ext foreign toplevel #49
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes `foreign_toplevel` in `ToplevelInfo` no longer an `Option`. Cosmic-comp has supported version 2 of this protocol for a while, so supporting version 1 is no longer necessary.
With this, `toplevel-monitor` works on Sway, but doesn't have the information exposed through the Cosmic protocol, naturally. The API is changed to use `ExtForeignToplevelHandleV1`. For convenience, `ToplevelInfo` contains the foreign handle, and the optional cosmic handle. I assume `identifier` is meant to be mandatory, so that is no longer an `Option` here. Though there's no check that the server sends this (is server-side code, this would send a protocol error; I guess cctk could panic, or log an error.)
This was referenced Feb 5, 2025
ids1024
added a commit
to pop-os/cosmic-applets
that referenced
this pull request
Feb 12, 2025
Requires pop-os/cosmic-protocols#49. The duplication between applets, and cosmic-workspace/xdg-desktop-portal-cosmic, should be moved to shared abstractions. But that can be done after moving to `ext-image-copy-capture`.
Instead of `Option<ToplevelInfo>`, filter out toplevels that don't have info. There isn't really any use for a handle without info, since it can't really be used for anything without knowing what toplevel it actually is. `ExtForeignToplevelHandleV1` is then redundant, since it's part of the `ToplevelInfo` now.
wash2
approved these changes
Feb 12, 2025
ids1024
added a commit
to pop-os/cosmic-applets
that referenced
this pull request
Feb 13, 2025
Requires pop-os/cosmic-protocols#49. The duplication between applets, and cosmic-workspace/xdg-desktop-portal-cosmic, should be moved to shared abstractions. But that can be done after moving to `ext-image-copy-capture`. `ToplevelInfo` now contains both ext and cosmic handles, so the tuples of handles and info are needed. Use just the info.
ids1024
added a commit
to pop-os/cosmic-applets
that referenced
this pull request
Feb 13, 2025
Requires pop-os/cosmic-protocols#49. The duplication between applets, and cosmic-workspace/xdg-desktop-portal-cosmic, should be moved to shared abstractions. But that can be done after moving to `ext-image-copy-capture`. `ToplevelInfo` now contains both ext and cosmic handles, so the tuples of handles and info are needed. Use just the info.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Supporting both cosmic toplevel info version 1 and foreign toplevel list (with cosmic toplevel info) seems awkward. So this initially make the cosmic-protocol mandatory and the ext protocol optional (without breaking the API). But now that Cosmic has supported this for a while, lets drop client-side support for the old version, and add support for other compositors implementing
ext-foreign-toplevel-list-v1.I still need to update users of the library for this. Probably after #46. Looks like
ext_foreign_toplevel_image_capture_source_manager_v1isn't currently implemented by Sway? So this doesn't yet capture windows on Sway.