feat!: Support secondary taps (right click) on new callbacks system#3741
feat!: Support secondary taps (right click) on new callbacks system#3741luanpotter merged 2 commits intomainfrom
Conversation
luanpotter
force-pushed
the
luan.secondary
branch
from
4b107d0 to
7a0133e
Compare
luanpotter
force-pushed
the
luan.secondary
branch
from
7a0133e to
27d1d2c
Compare
spydon
left a comment
spydon
left a comment
There was a problem hiding this comment.
Lgtm, just one minor comment on the example
| } | ||
| } | ||
|
|
||
| class TappableSquare extends PositionComponent |
There was a problem hiding this comment.
Why not extend RectangleComponent?
There was a problem hiding this comment.
this is in line with how the other tap examples do it; I can followup and update all so they are consistent
|
@felangel I was wondering if it was possible to add a link to the github check so we can see more details? |
I’m investigating right now |
|
Can you try closing and reopening the pr in the meantime? |
Pull request was closed
|
FWIW, I'm also using middle click in my game (once you're on desktop and using keyboard+mouse input, you want to give players as many options as possible). I'm sharing it here just as a piece of context for later. I have my own workaround (I'm getting my clicks from The good news that there are no more buttons, basically. It's (from |
…lame-engine#3741) Support secondary taps (right click) on new callbacks system. In order to follow through with our [event system migration](https://docs.google.com/document/d/1nBUup9QCPioVwWL1zs79z1hWF882tAYfNywFMdye2Qc), we need to make sure the new system is equipped to support all use cases; also changes the existing TapCallbacks to be primary-only. I noticed that we don't support "secondary taps" (i.e. right clicks), so I am adding this. I honestly really dislike the fact that this is considered a completely different event from the left click, instead of just a property on the click event. But I kept this structure to replicate what Flutter does, so this is more familiar for users. I think that is worth the slight verbosity of having yet another detector. Also, it plays well this way with Flutter because that underlying events are a bit different (for example, the secondary ones don't support `pointId`). Note: this is a slight breaking change because the existing detector works for BOTH left and right click, but there is NO WAY of distinguishing them because the `buttons` property is not propagated in the Flutter end (massive oversight I believe - might put a PR later). Since this provides the secondary as a solution, it also removes secondary clicks from triggering the primary. I think this is more versatile than having tap detector=`(primary OR secondary)` and secondary=`(secondary only)`. I don't think this should affect basically any users because (1) desktop only and (2) this acceptance of right clicks was probably a bug anyway (for example, on the example it would rotate the square and also open the context menu, which is jarring). However I am happy to add an option or pursue a different approach, I believe this is the best path forward, IMO.
…lame-engine#3745) Update input examples to use `RectangleComponent` where sensible. Minor simplification as suggested by @spydon on flame-engine#3741
4 participants
Description
Support secondary taps (right click) on new callbacks system.
In order to follow through with our event system migration, we need to make sure the new system is equipped to support all use cases; also changes the existing TapCallbacks to be primary-only.
I noticed that we don't support "secondary taps" (i.e. right clicks), so I am adding this. I honestly really dislike the fact that this is considered a completely different event from the left click, instead of just a property on the click event. But I kept this structure to replicate what Flutter does, so this is more familiar for users. I think that is worth the slight verbosity of having yet another detector. Also, it plays well this way with Flutter because that underlying events are a bit different (for example, the secondary ones don't support
pointId).Note: this is a slight breaking change because the existing detector works for BOTH left and right click, but there is NO WAY of distinguishing them because the
buttonsproperty is not propagated in the Flutter end (massive oversight I believe - might put a PR later). Since this provides the secondary as a solution, it also removes secondary clicks from triggering the primary. I think this is more versatile than having tap detector=(primary OR secondary)and secondary=(secondary only).I don't think this should affect basically any users because (1) desktop only and (2) this acceptance of right clicks was probably a bug anyway (for example, on the example it would rotate the square and also open the context menu, which is jarring).
However I am happy to add an option or pursue a different approach, I believe this is the best path forward, IMO.
Checklist
docsand added dartdoc comments with///.examplesordocs.Breaking Change?