follow=keyboard: Fall back to follow=mouse instead of XDefaultScreen()#708
Merged
Conversation
Contributor
Author
|
Video demonstration of the problem and solution, with dunst HEAD first, and dunst with this patch after: |
In dwm and similar window managers, it's common to often have empty tags, and navigate to them with the intent to create clients there. If I navigate to one of those empty tags with a dunst notification visible and follow=keyboard set, the notification warps over to the default screen. If I then open a client, it then warps back, which is pretty jarring. This is mostly an artefact of the implementation of follow=keyboard -- if we fail to get a focused window, we use the default screen. However this case isn't necessarily really a "failure" on window managers like dwm where it's a common occurrence to end up with no clients on the screen, whereas that would be significantly rarer on (say) GNOME or KDE. A guess that's more likely to fit user expectations is falling back to where the mouse pointer currently is, since this indicates the currently focused monitor that the window manager would create a client on. This avoids warping back to that monitor again when a client is created.
Codecov Report
@@ Coverage Diff @@
## master #708 +/- ##
==========================================
+ Coverage 67.13% 67.24% +0.10%
==========================================
Files 29 29
Lines 5006 4995 -11
==========================================
- Hits 3361 3359 -2
+ Misses 1645 1636 -9
Continue to review full report at Codecov.
|
tsipinakis
approved these changes
Apr 27, 2020
tsipinakis
left a comment
tsipinakis
left a comment
Member
There was a problem hiding this comment.
LGTM 👍 Thanks for taking the time to fix it!
Contributor
Author
|
Thanks for the quick review! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
In dwm and similar window managers, it's common to often have empty
tags, and navigate to them with the intent to create clients there. If I
navigate to one of those empty tags with a dunst notification visible
and follow=keyboard set, the notification warps over to the default
screen. If I then open a client, it then warps back, which is pretty
jarring.
This is mostly an artefact of the implementation of follow=keyboard --
if we fail to get a focused window, we use the default screen. However
this case isn't necessarily really a "failure" on window managers like
dwm where it's a common occurrence to end up with no clients on the
screen, whereas that would be significantly rarer on (say) GNOME or KDE.
A guess that's more likely to fit user expectations is falling back to
where the mouse pointer currently is, since this indicates the currently
focused monitor that the window manager would create a client on. This
avoids warping back to that monitor again when a client is created.