Holder Events #521

Open
opened 2026-02-20 10:18:20 -05:00 by deekerman · 3 comments
Owner

Originally created by @robartsd on GitHub (May 13, 2022).

We know that holder events don't work as we want them to, but we haven't really defined how we want them to work. This is a draft of what I think should happen.

Widget dragged from HolderA to HolderB

  1. mousedown/touchstart followed by mousemove/touchmove triggers beginning of drag
  2. Widget.parent set to null
  3. call HolderA.beforeLeaveRoutine (mitigate that leave routine no longer fires twice by adding beforeLeaveRoutine that calls leaveRoutine via fileupdater)
  4. mousemove/touchmove events move widget - HolderA is no longer hoverTarget
  5. change Widget properties based on HolderA.childrenPerOwner and HolderA.onLeave
  6. call HolderA.leaveRoutine
  7. mousemove/touchmove events move widget - HolderB becomes hoverTarget
  8. mouseup/touchend event completes the move
  9. Widget.parent set to HolderB.id
  10. change Widget properties based on HolderB.childrenPerOwner, HolderB.onEnter, HolderB.alignChildren
  11. resolve piles
  12. call HolderA.afterLeaveRoutine
  13. call HolderB.enterRoutine

Widget dragged into HolderB

  1. mousedown/touchstart followed by mousemove/touchmove triggers beginning of drag
  2. mousemove/touchmove events move widget - HolderB becomes hoverTarget
  3. mouseup/touchend event completes the move
  4. Widget.parent set to HolderB.id
  5. change Widget properties based on HolderB.childrenPerOwner, HolderB.onEnter, HolderB.alignChildren
  6. resolve piles
  7. call HolderB.enterRoutine

Widget dragged out of HolderA

  1. mousedown/touchstart followed by mousemove/touchmove triggers beginning of drag
  2. Widget.parent set to null
  3. call HolderA.beforeLeaveRoutine
  4. mousemove/touchmove events move widget - HolderA is no longer hoverTarget
  5. change Widget properties based on HolderA.childrenPerOwner and HolderA.onLeave
  6. call HolderA.leaveRoutine
  7. mouseup/touchend event completes the move
  8. resolve piles
  9. call HolderA.afterLeaveRoutine

Widget dragged within HolderA (Holder is always hoverTarget during the move)

  1. mousedown/touchstart followed by mousemove/touchmove triggers beginning of drag
  2. Widget.parent set to null
  3. call HolderA.beforeLeaveRoutine
  4. mouseup/touchend event completes the move
  5. Widget.parent set to HolderA.id
  6. change Widget properties based on HolderA.childrenPerOwner, HolderA.onEnter, HolderA.alignChildren
  7. resolve piles
  8. call HolderA.leaveCancelledRoutine with flag indicating that leaveRoutine was not called

Widget dragged out of HolderA, but returns to HolderA before being dropped

  1. mousedown/touchstart followed by mousemove/touchmove triggers beginning of drag
  2. Widget.parent set to null
  3. call HolderA.beforeLeaveRoutine
  4. mousemove/touchmove events move widget - HolderA is no longer hoverTarget
  5. change Widget properties based on HolderA.childrenPerOwner and HolderA.onLeave
  6. call HolderA.leaveRoutine
  7. mousemove/touchmove events move widget - HolderA becomes hoverTarget
  8. mouseup/touchend event completes the move
  9. Widget.parent set to HolderA.id
  10. change Widget properties based on HolderA.childrenPerOwner, HolderA.onEnter, HolderA.alignChildren
  11. resolve piles
  12. call HolderA.leaveCancelledRoutine with flag indicating that leaveRoutine was called

MOVE Widget from HolderA to HolderB

  1. MOVE encounted moving Widget
  2. change Widget properties based on HolderA.childrenPerOwner and HolderA.onLeave
  3. call HolderA.leaveRoutine with flag indicating that widget was moved by a routine
  4. Widget.parent set to HolderB.id
  5. change Widget properties based on HolderB.childrenPerOwner, HolderB.onEnter
  6. position Widget in holder regardless of HolderB.alignChildren
  7. resolve piles
  8. call HolderA.afterLeaveRoutine with flag indicating that widget was moved by a routine
  9. call HolderB.enterRoutine with flag indicating that widget was moved by a routine
  10. resume processing routine where MOVE was encountered

MOVEXY Widget from HolderA

  1. MOVEXY encounted moving Widget
  2. change Widget properties based on HolderA.childrenPerOwner and HolderA.onLeave
  3. call HolderA.leaveRoutine with flag indicating that widget was moved by a routine
  4. Widget.parent set to null
  5. set Widget position
  6. resolve piles
  7. call HolderA.afterLeaveRoutine with flag indicating that widget was moved by a routine
  8. resume processing routine where MOVEXY was encountered

MOVE Widget to HolderB (after collection support is added for MOVE)

  1. MOVE encounted moving Widget
  2. Widget.parent set to HolderB.id
  3. change Widget properties based on HolderB.childrenPerOwner, HolderB.onEnter
  4. position Widget in holder regardless of HolderB.alignChildren
  5. resolve piles
  6. call HolderB.enterRoutine with flag indicating that widget was moved by a routine
  7. resume processing routine where MOVE was encountered
Originally created by @robartsd on GitHub (May 13, 2022). We know that holder events don't work as we want them to, but we haven't really defined how we want them to work. This is a draft of what I think should happen. ### Widget dragged from HolderA to HolderB 1. mousedown/touchstart followed by mousemove/touchmove triggers beginning of drag 2. Widget.`parent` set to null 3. call HolderA.`beforeLeaveRoutine` (mitigate that leave routine no longer fires twice by adding `beforeLeaveRoutine` that calls `leaveRoutine` via fileupdater) 4. mousemove/touchmove events move widget - HolderA is no longer hoverTarget 5. change Widget properties based on HolderA.`childrenPerOwner` and HolderA.`onLeave` 6. call HolderA.`leaveRoutine` 7. mousemove/touchmove events move widget - HolderB becomes hoverTarget 8. mouseup/touchend event completes the move 9. Widget.`parent` set to HolderB.`id` 10. change Widget properties based on HolderB.`childrenPerOwner`, HolderB.`onEnter`, HolderB.`alignChildren` 11. resolve piles 12. call HolderA.`afterLeaveRoutine` 13. call HolderB.`enterRoutine` ### Widget dragged into HolderB 1. mousedown/touchstart followed by mousemove/touchmove triggers beginning of drag 7. mousemove/touchmove events move widget - HolderB becomes hoverTarget 8. mouseup/touchend event completes the move 9. Widget.`parent` set to HolderB.`id` 10. change Widget properties based on HolderB.`childrenPerOwner`, HolderB.`onEnter`, HolderB.`alignChildren` 11. resolve piles 12. call HolderB.`enterRoutine` ### Widget dragged out of HolderA 1. mousedown/touchstart followed by mousemove/touchmove triggers beginning of drag 2. Widget.`parent` set to null 3. call HolderA.`beforeLeaveRoutine` 4. mousemove/touchmove events move widget - HolderA is no longer hoverTarget 5. change Widget properties based on HolderA.`childrenPerOwner` and HolderA.`onLeave` 6. call HolderA.`leaveRoutine` 8. mouseup/touchend event completes the move 9. resolve piles 12. call HolderA.`afterLeaveRoutine` ### Widget dragged within HolderA (Holder is always hoverTarget during the move) 1. mousedown/touchstart followed by mousemove/touchmove triggers beginning of drag 2. Widget.`parent` set to null 3. call HolderA.`beforeLeaveRoutine` 8. mouseup/touchend event completes the move 10. Widget.`parent` set to HolderA.`id` 11. change Widget properties based on HolderA.`childrenPerOwner`, HolderA.`onEnter`, HolderA.`alignChildren` 12. resolve piles 13. call HolderA.`leaveCancelledRoutine` with flag indicating that `leaveRoutine` was not called ### Widget dragged out of HolderA, but returns to HolderA before being dropped 1. mousedown/touchstart followed by mousemove/touchmove triggers beginning of drag 2. Widget.`parent` set to null 3. call HolderA.`beforeLeaveRoutine` 4. mousemove/touchmove events move widget - HolderA is no longer hoverTarget 5. change Widget properties based on HolderA.`childrenPerOwner` and HolderA.`onLeave` 6. call HolderA.`leaveRoutine` 7. mousemove/touchmove events move widget - HolderA becomes hoverTarget 8. mouseup/touchend event completes the move 9. Widget.`parent` set to HolderA.`id` 10. change Widget properties based on HolderA.`childrenPerOwner`, HolderA.`onEnter`, HolderA.`alignChildren` 11. resolve piles 12. call HolderA.`leaveCancelledRoutine` with flag indicating that `leaveRoutine` was called ### `MOVE` Widget from HolderA to HolderB 1. MOVE encounted moving Widget 2. change Widget properties based on HolderA.`childrenPerOwner` and HolderA.`onLeave` 3. call HolderA.`leaveRoutine` with flag indicating that widget was moved by a routine 4. Widget.`parent` set to HolderB.`id` 5. change Widget properties based on HolderB.`childrenPerOwner`, HolderB.`onEnter` 6. position Widget in holder regardless of HolderB.`alignChildren` 7. resolve piles 8. call HolderA.`afterLeaveRoutine` with flag indicating that widget was moved by a routine 9. call HolderB.`enterRoutine` with flag indicating that widget was moved by a routine 10. resume processing routine where MOVE was encountered ### `MOVEXY` Widget from HolderA 1. MOVEXY encounted moving Widget 2. change Widget properties based on HolderA.`childrenPerOwner` and HolderA.`onLeave` 3. call HolderA.`leaveRoutine` with flag indicating that widget was moved by a routine 4. Widget.`parent` set to null 5. set Widget position 6. resolve piles 7. call HolderA.`afterLeaveRoutine` with flag indicating that widget was moved by a routine 11. resume processing routine where MOVEXY was encountered ### `MOVE` Widget to HolderB (after collection support is added for MOVE) 1. MOVE encounted moving Widget 4. Widget.`parent` set to HolderB.`id` 5. change Widget properties based on HolderB.`childrenPerOwner`, HolderB.`onEnter` 6. position Widget in holder regardless of HolderB.`alignChildren` 7. resolve piles 9. call HolderB.`enterRoutine` with flag indicating that widget was moved by a routine 10. resume processing routine where MOVE was encountered
Author
Owner

@96LawDawg commented on GitHub (May 14, 2022):

Wow. That is an impressive amount of thought and work on the structure. Other than rooms with hacky workarounds for leaveRoutine firing twice, do you think this will break anything? I'm not sure I have the capacity to follow or understand the consequences.

@96LawDawg commented on GitHub (May 14, 2022): Wow. That is an impressive amount of thought and work on the structure. Other than rooms with hacky workarounds for `leaveRoutine` firing twice, do you think this will break anything? I'm not sure I have the capacity to follow or understand the consequences.
Author
Owner

@mousewax commented on GitHub (May 14, 2022):

Is this an appropriate place to add my wish list item for "showMouseCursor": false specifically for holders?

@mousewax commented on GitHub (May 14, 2022): Is this an appropriate place to add my wish list item for `"showMouseCursor": false` specifically for holders?
Author
Owner

@robartsd commented on GitHub (May 15, 2022):

I'm not sure I have the capacity to follow or understand the consequences.

Me either. I just was thinking enough about this that I thought it warranted a record here. I don't have significant ideas on how it to implement or what the ramifications it could have on existing games.

@robartsd commented on GitHub (May 15, 2022): > I'm not sure I have the capacity to follow or understand the consequences. Me either. I just was thinking enough about this that I thought it warranted a record here. I don't have significant ideas on how it to implement or what the ramifications it could have on existing games.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/virtualtabletop#521
No description provided.