Conversation
1 task
ids1024
added a commit
to ids1024/smithay
that referenced
this pull request
Apr 30, 2026
Based on Smithay#2008. Beyond what that PR does, this also allows the availablility of `Dispatch` implementations to be inferred usually by just the `*Handler` trait for the protocol. Though it looks like Rust still can't infer bounds like `<D as SeatHandler>::KeyboardFocus: WaylandFocus` from placing them on the trait (*eventually* it should?). Uses Smithay/wayland-rs#902.
ids1024
added a commit
to ids1024/client-toolkit
that referenced
this pull request
May 19, 2026
For Smithay/wayland-rs#902, and eliminating `delegate_!` macros, we won't be able to implement `Dispatch` for a udata type that is not our own. So of letting the application define a data type wrapping the sctk one with a trait, reverse that. In some ways not having traits, etc. is a bit simpler here. This opens up the possibility for things like keyboard to use the builder pattern for all the various options that can be used when binding a keyboard. But that isn't changed here. Prior to this, `delegate_data_device!` doesn't seem to have had a way to implement dispatch for a custom type, despite having an extension trait. The input method code also seems to have been broken for custom types, not handling it in the delegate macro, not providing a method to create an instance with custom data, and assuming the default type in `.commit()`. These things are fixed here. `RequestDataExt` was defined a bit different from other things here, with multiple methods instead of one returning a shared struct. But it should still be fine to replace that with an immutable wrapper struct.
ids1024
added a commit
to ids1024/client-toolkit
that referenced
this pull request
May 19, 2026
Smithay/wayland-rs#902 will replace `Dispatch` with a trait defined this way. `Dispatch2` is a prototype to prove that works, and an incremental change toward that. I think for `delegate_registry!` we'll want a change to the API wayland-client provides, so that is unchanged for now. This makes it simpler to add protocols to sctk, and seems overall a little bit better for client code using sctk. Once the wayland-rs update is done, the `Dispatch` type bounds will be cleaner, and the compiler should provide nicer error messages about missing `*Handler` traits.
ids1024
added a commit
to ids1024/smithay
that referenced
this pull request
May 19, 2026
Based on Smithay#2008. Beyond what that PR does, this also allows the availablility of `Dispatch` implementations to be inferred usually by just the `*Handler` trait for the protocol. Though it looks like Rust still can't infer bounds like `<D as SeatHandler>::KeyboardFocus: WaylandFocus` from placing them on the trait (*eventually* it should?). Uses Smithay/wayland-rs#902.
By defining these traits as implemented by the user-data type, as long as `smithay` and `smithay-client-toolkit` define their own user data type, they can simply provide generic implementations, without dispatch macros. `delegate_dispatch!` and `delegate_global_dispatch!` are removed. `delegate_noop!` has been replaced with `Noop` and `NoopIgnore` types providing a generic impl (we could still provide a macro if that's better, but this seems like a good way of doing things). This has basic changelog entries, but we may want a more thorough migration guide for this release. This is a major breaking change.
ids1024
changed the title
Dispatch API simplificationDispatch/GlobalDispatch API simplification
Closed
wash2
pushed a commit
to Smithay/client-toolkit
that referenced
this pull request
May 20, 2026
For Smithay/wayland-rs#902, and eliminating `delegate_!` macros, we won't be able to implement `Dispatch` for a udata type that is not our own. So of letting the application define a data type wrapping the sctk one with a trait, reverse that. In some ways not having traits, etc. is a bit simpler here. This opens up the possibility for things like keyboard to use the builder pattern for all the various options that can be used when binding a keyboard. But that isn't changed here. Prior to this, `delegate_data_device!` doesn't seem to have had a way to implement dispatch for a custom type, despite having an extension trait. The input method code also seems to have been broken for custom types, not handling it in the delegate macro, not providing a method to create an instance with custom data, and assuming the default type in `.commit()`. These things are fixed here. `RequestDataExt` was defined a bit different from other things here, with multiple methods instead of one returning a shared struct. But it should still be fine to replace that with an immutable wrapper struct.
wash2
pushed a commit
to Smithay/client-toolkit
that referenced
this pull request
May 20, 2026
Smithay/wayland-rs#902 will replace `Dispatch` with a trait defined this way. `Dispatch2` is a prototype to prove that works, and an incremental change toward that. I think for `delegate_registry!` we'll want a change to the API wayland-client provides, so that is unchanged for now. This makes it simpler to add protocols to sctk, and seems overall a little bit better for client code using sctk. Once the wayland-rs update is done, the `Dispatch` type bounds will be cleaner, and the compiler should provide nicer error messages about missing `*Handler` traits.
ids1024
added a commit
to ids1024/smithay
that referenced
this pull request
May 20, 2026
Based on Smithay#2008. Beyond what that PR does, this also allows the availablility of `Dispatch` implementations to be inferred usually by just the `*Handler` trait for the protocol. Though it looks like Rust still can't infer bounds like `<D as SeatHandler>::KeyboardFocus: WaylandFocus` from placing them on the trait (*eventually* it should?). Uses Smithay/wayland-rs#902.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
See Smithay/client-toolkit#519 and Smithay/smithay#2008.