Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WISH: ALL View events to populate their flags properly #161

Open
hiiamboris opened this issue Feb 21, 2024 · 2 comments
Open

WISH: ALL View events to populate their flags properly #161

hiiamboris opened this issue Feb 21, 2024 · 2 comments

Comments

@hiiamboris
Copy link

hiiamboris commented Feb 21, 2024

It seems that pointer & wheel events properly report pushed modifier keys, and key events properly report pushed pointing device buttons. However time, moving, resizing, probably other events I haven't tested always keep their flags empty and ctrl? shift? down? etc. flags false. offset is also unset for anything but pointer and wheel events.

I suggest that View should track these flags state internally and put that state into events for which OS does not provide such info. I also suggest ensuring last known offset (relative to the face receiving the event) is reported by keyboard, timer and other events.

Use case examples:

  • in Spaces I synthesize over events from time events when pointer is still but one of the underlying spaces moves, and have to track these flags and offset on my own
  • one could make keys function like pointing device buttons for some customized UX

P.S. On Red level providing offset to time events becomes rather messy, because faces screen offsets are not immediately known.

@hiiamboris hiiamboris changed the title WISH: **all** View events to populate their flags properly WISH: ALL View events to populate their flags properly Feb 21, 2024
@mikeyaunish
Copy link

Having unfocus report the keys that generate the unfocus action (if there are any) would allow a field to know the correct behaviour needed to respond to this change of state.

Use case examples:

  • Knowing when the tab key has been pressed during the unfocus action is critical for data validation
  • Pressing tab and pressing enter at a field needs to be determined to know where the cursor goes next ( similar to spreadsheet behaviour)

@hiiamboris
Copy link
Author

hiiamboris commented Jun 15, 2024

My thoughts:

  • about tab/enter: Tab follows z-order, so solution is simply to lay out fields in rows, then make Enter skip rows
  • data validation: I think should be baked into the field, so no language user would have to bother with it

Though in general we may not anticipate some use cases, and the whole idea of fine tuning based on event info is valid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants