[WIP] Prototype a Dispatch2 trait to dispatch delegate macros to oblivion#519
Draft
ids1024 wants to merge 15 commits into
Draft
[WIP] Prototype a Dispatch2 trait to dispatch delegate macros to oblivion#519ids1024 wants to merge 15 commits into
Dispatch2 trait to dispatch delegate macros to oblivion#519ids1024 wants to merge 15 commits into
Conversation
ids1024
force-pushed
the
dispatch2
branch
2 times, most recently
from
4799e6d to
3307616
Compare
Presumably the type argument for the `LoopHandle` is expected to match the the `D` type used for wayland-rs dispatch? Unless the calloop event loop isn't being used to dispatch Wayland events. Without `keyboard:` specified in `delegate_keyboard!`, this did use `KeyboardData<$ty>`, so in that case these are assumed to match.
WIP surface udata fix macro macro WIP pointer macro WIP DataSourceData macro did earlier version not actually provide any way to implement dispatch for custom type here? constructor and accessors pub constructors touch WIP activation not compiling types in example? should be fine to get rid of trait and just rely on immutable wrapper struct. WIP don't make `delegate_activation!` generic Not compiling... can that work? see how that works with new wayland-rs. input method should fix custom data types previously was seemingly broken for delegating dispatch, constructing with custom data, or commit() aaccessing `.data` input-method-v3
example WIP WIP WIP WIP examples
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.
I've though of some alternate ways to define
Dispatch(as an alternative to the change in Smithay/smithay#1327). Today I had an idea for a way to prototype such a thing outside ofwayland-rs. Due to the orphan rule, we can't create any blanket impls ofDispatchthat are generic over theStatethe trait is implemented for (unless our crate is the one that defined the typeI). But we can provide adelegate_dispatch2!macro that will add such a blanket impl for a particular concrete type.Dispatch2is similar towayland_client::Dispatch, but it's now implemented for the object user data type instead of the state type, uses&selffor the argument pointer to the user data, and removes the extraState = Selftype bound.Implementing this for the user data seems reasonable, since we already need to pass a user data when sending a request that creates an object. So the type passed there indicates what dispatch implementation to use. (It would also work to use
State: Dispatch<UserData, I>instead ofUserData: Dispatch<I, State>; but it would not work to useState: Dispatch<I, UserData>whereIis a type from a different crate andStateis generic. That isn't allowed under the orphan rule. So of the alternatives that work, this draft uses the one that seemed best to me.)This draft uses
Dispatch2and eliminates the dispatch macros used in thesimple_windowexample, except:KeyboardDataExt,PointerDataExt,SurfaceDataExt,RequestDataExt(at least if this trait were part of wayland-rs, and not the same crate)GlobalListtype, since that is awayland-clienttype, not an sctk oneevent_created_child()is unchanged, but we should think of better ways to handle that too.It is still necessary to have
Dispatchbounds in methods of the*Statetypes that create objects, but not in the implementations ofDispatch2. Though type bounds shouldn't be needed anymore if this were moved to wayland-rs and replacedDispatch.If an API change like this is good, it could be incorporated in the next breaking update to wayland-rs. Does anyone see non-obvious issues with this?