cmyr
commented
4 years ago Just saw this, excellent stuff, thanks!
Open xStrom opened 4 years ago
cmyr
commented
4 years ago Just saw this, excellent stuff, thanks!
Background
This survey got started because of #821, which is related to #558 / #541.
I tested behavior on Windows 7 SP1, macOS Catalina, Ubuntu 19.04. The testing was done with druid master 3ffe5e4 (macOS / Linux) and #821 (Windows).
Data
Topmost = The druid window has the highest z-order and no other window no matter where they are located will occlude the druid window. Occlusion = When another window has a higher z-order than druid and is blocking the view to parts of the druid window. ⚠️ = Most pressing issues. ⌛ = It happens but not instantly.
HotChange(true)when window is gaining topmost statusHotChange(true)when window is gaining topmost status after clicking and holding the mouse button in another applicationHotChange(false)when window is losing topmost statusHotChange(false)when window is losing topmost status after clicking and holding the mouse button in druid windowHotChange(false)when cursor moves to occluded part of the windowHotChange(false)when cursor leaves the window via an occluded partHotChange(false)when cursor leaves the window via a non-occluded partHotChange(false)when cursor moves to occluded part of the windowHotChange(false)when cursor moves to occluded part of the window and then releasing holdHotChange(false)when cursor moves to occluded part of the window and then releasing hold + movingHotChange(false)when cursor leaves the window via an occluded partHotChange(false)when cursor leaves the window via an occluded part and then releasing holdHotChange(false)when cursor leaves the window via an occluded part and then releasing hold + movingHotChange(false)when cursor leaves the window via a non-occluded partHotChange(false)when cursor leaves the window via a non-occluded part and then releasing holdHotChange(false)when cursor leaves the window via a non-occluded part and then releasing hold + movingDiscussion
A bunch of these differences don't necessarily matter and will just give the druid app an OS-feel. Things like macOS not being able to show hover effects when the window isn't topmost, or Windows not showing hover effects for elements that are being occluded by other windows. However some of the differences here actually pinpoint more significant issues.
Windows
When we are capturing the mouse after
MouseDownand the window loses topmost status or loses its capture state for any other reason, then we won't get aMouseUpunless it happens over a non-occluded part of our window. Maybe it's possible to re-capture somehow? If not, then there are two ways to solve this. One is to do nothing and document that not everyMouseDownhas a companionMouseUpand vice versa. An alternative solution would be to add aMouseCancelevent which druid will synthesize whenever aMouseDownevent arrives before the previousMouseDownreceived itsMouseUp.Thus it's educating to handle
MouseCancelor educating thatMouseUpandMouseDownare independent calls and can be dropped.This issue also touches on what I mentioned in #396 where
MouseUpwas being eaten my modal dialogs. I hope to get back to that modal issue testing in a few weeks.macOS
The main issue is if the window is hot and then it loses its topmost status, e.g Command+Tab. The window won't receive any more events but the hot status doesn't get reset. Maybe there's an event for when the window loses its topmost status? While handling that event could check if the mouse is captured (
MouseDown+ hold) and if not, then reset all hot states as we won't be receiving any more mouse events.Linux/GTK
Linux receives mouse events even when not topmost, however the hot state can remain stuck when leaving the window area via and occluded area. Hopefully there's a way to handle this.