Skip to content

Instantly share code, notes, and snippets.

@torarnv
Last active October 11, 2016 12:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save torarnv/7bc8b7e981e96f6a7164365319e41d5b to your computer and use it in GitHub Desktop.
Save torarnv/7bc8b7e981e96f6a7164365319e41d5b to your computer and use it in GitHub Desktop.

Alternative 1: Injecting QPA::MouseEvent to QPA event queue

Injects a MouseRelease event at the start of the QPA event queue, and turns the current release event into a move event, which is then processed.

Good

  • If eventloop/processevent is run from MouseMove event, will deliver MouseRelease before any new mouse events.

Bad

  • Messes with QPA queue from Gui, bad
  • If eventloop/processevent is run from MouseMove event, will return to user code for MouseMove after corresponding MouseEnd has been delivered, and then return to Gui code for the same MouseMove, which may not be happy that the End was delivered.

Alternative 2: Process QPA::MouseMove synchronously in Gui before processing MouseRelease

Good

  • Stays within Gui for delivery (alghtough it does create QWindowSystemInterfacePrivate::MouseEvent instead of QMouseEvent)
  • Keeps order of events for the single source event that trigggered move + release

Bad

  • If eventloop/processevent is run from MouseMove event, will not deliver MouseEnd for the current event, and may start delivering new mouse events, eg: Press[A], Move[A], Move[A], Press[B], Move[B], Move[B], Release[B], Release[A]

The release of A should happen before Press of B.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment