Revised the location queries for determining if a window contains a given point #22
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have addressed the points raised in #20 (original pull request was #15). The default coordinates used are based on the active monitor, however there is a boolean xml attribute "global" that can be added to the containsxpoint and containsypoint queries in order to treat the points as global coordinates, not just for the active monitor.
With an asymmetrical monitor setup (e.g. a 4k screen next to a 1080p screen, like my current setup at work) the global coordinates would be less useful in my opinion, however with symmetrical setups of monitors (e.g. 4 1080p monitors in a grid) especially with higher numbers of monitors, global coordinates could be quite useful. For example in a 4 monitor grid setup (2x2) if a user typically had up to 4 windows in a grid (2x2) on each screen, then the user could use some modifier keys (e.g. W-C) with the keys in the 4x4 grid of 1-4, q-r, a-f, z-v and quickly switch between windows.