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

X.H.ManageDocks.AvoidStruts breaks dropdown menus on multi-monitor screens #73

Closed
Narthorn opened this Issue Aug 9, 2016 · 8 comments

Comments

Projects
None yet
4 participants
@Narthorn

Narthorn commented Aug 9, 2016

Starting a few months ago, dropdown menus in some applications sometimes stop working when the window is on one screen, then seem to work again with the window on the other screen - only for them to stop working again after changing to another workspace.

The reason for the bug is that AvoidStruts calculates _NET_WORKAREA for the root window using the position, dimensions and struts of only one screen, and updates it whenever a window is mapped on that screen. Hence, on multi-monitor setups, when swapping windows from one screen to another, the calculated workarea often ends up not being the correct one for the currently focused window.

This affects several applications, notably chromium, most Qt apps (due to similar use of the workarea rectangle to make dropdowns avoid struts), and it probably also affects all applications that rely on _NET_WORKAREA for any purpose.

This issue was noted before in https://code.google.com/archive/p/xmonad/issues/158 (comment 12), and https://code.google.com/archive/p/xmonad/issues/526. It seems generally agreed that _NET_WORKAREA is unsuited for multi-monitor setups with docks in-between screens, but in this case, applications will break regardless of where the docks are.

I'm not sure what the best solution is for this. One way would be to make xmonad calculate and store the workarea for each screen in _NET_WORKAREA, but this also would require patches to client applications since most of them only ever look at the first 4 values of the property. The other way would be to drop support for _NET_WORKAREA altogether ; this is what i3 and awesome ended up doing long ago, basically for the same reasons.

@geekosaur

This comment has been minimized.

Show comment
Hide comment
@geekosaur

geekosaur Aug 9, 2016

Contributor

The problem with just dropping _NET_WORKAREA is that this allows desktop backdrops to position things behind docks (and some desktop-window file managers will spam incessantly about missing _NET_WORAKREA).

For what it's worth, I have been experimentally setting _NET_WORKAREA to a hardcoded constant value which incorrectly claims I have the same docks everywhere, since _NET_WORKAREA assumes the EWMH workspace model which does not map to xmonad's workspace model. Both Qt's menus and Chrome's dropdown menus are working now, where they didn't before.

-- @@@@@@@@ HAAAAAAAAAACK
setWorkArea :: X ()
setWorkArea = withDisplay $ \dpy -> do
    a <- getAtom "_NET_WORKAREA"
    c <- getAtom "CARDINAL"
    r <- asks theRoot
    io $ changeProperty32 dpy r a c propModeReplace (concat $ replicate (length workspacen) [0, 26, 3840, 1028])
Contributor

geekosaur commented Aug 9, 2016

The problem with just dropping _NET_WORKAREA is that this allows desktop backdrops to position things behind docks (and some desktop-window file managers will spam incessantly about missing _NET_WORAKREA).

For what it's worth, I have been experimentally setting _NET_WORKAREA to a hardcoded constant value which incorrectly claims I have the same docks everywhere, since _NET_WORKAREA assumes the EWMH workspace model which does not map to xmonad's workspace model. Both Qt's menus and Chrome's dropdown menus are working now, where they didn't before.

-- @@@@@@@@ HAAAAAAAAAACK
setWorkArea :: X ()
setWorkArea = withDisplay $ \dpy -> do
    a <- getAtom "_NET_WORKAREA"
    c <- getAtom "CARDINAL"
    r <- asks theRoot
    io $ changeProperty32 dpy r a c propModeReplace (concat $ replicate (length workspacen) [0, 26, 3840, 1028])
@Narthorn

This comment has been minimized.

Show comment
Hide comment
@Narthorn

Narthorn Aug 11, 2016

_NET_WORKAREA assumes the EWMH workspace model which does not map to xmonad's workspace model.

I'm not entirely sure what EWMH expects to be in _NET_WORKAREA, but wouldn't it be possible just to store the workarea for each visible xmonad workspace in the corresponding slot in _NET_WORKAREA, based on which monitor that workspace is currently on ?

For example, with a dual-monitor setup like this:

|‾‾‾‾‾‾‾‾‾‾‾||‾‾‾16px dock‾‾‾|
| 1680x1050 ||               |
|___________||   1900x1200   |
 workspace 2 |_______________|
                workspace 0

_NET_WORKAREA would contain this:

  /‾‾‾workspace 0‾‾‾‾\              /‾‾workspace 2‾\
 [1680, 16, 1900, 1184, 0, 0, 0, 0, 0, 0, 1680, 1050, 0, 0, 0, ...]
  \___right screen___/              \__left screen_/   

This seems to be what GDK expects, as it first retrieves the number of the active workspace through _NET_CURRENT_DESKTOP before using that to get the right workarea.

_NET_WORKAREA assumes the EWMH workspace model which does not map to xmonad's workspace model.

I'm not entirely sure what EWMH expects to be in _NET_WORKAREA, but wouldn't it be possible just to store the workarea for each visible xmonad workspace in the corresponding slot in _NET_WORKAREA, based on which monitor that workspace is currently on ?

For example, with a dual-monitor setup like this:

|‾‾‾‾‾‾‾‾‾‾‾||‾‾‾16px dock‾‾‾|
| 1680x1050 ||               |
|___________||   1900x1200   |
 workspace 2 |_______________|
                workspace 0

_NET_WORKAREA would contain this:

  /‾‾‾workspace 0‾‾‾‾\              /‾‾workspace 2‾\
 [1680, 16, 1900, 1184, 0, 0, 0, 0, 0, 0, 1680, 1050, 0, 0, 0, ...]
  \___right screen___/              \__left screen_/   

This seems to be what GDK expects, as it first retrieves the number of the active workspace through _NET_CURRENT_DESKTOP before using that to get the right workarea.

@geekosaur

This comment has been minimized.

Show comment
Hide comment
@geekosaur

geekosaur Aug 11, 2016

Contributor

On Thu, Aug 11, 2016 at 11:59 AM, Vincent Vinel notifications@github.com
wrote:

I'm not entirely sure what EWMH expects to be in _NET_WORKAREA, but
wouldn't it be possible just to store the workarea for each visible xmonad
workspace in the corresponding slot in _NET_WORKAREA, based on which
monitor that workspace is currently on ?

There are programs that break if you don't have values for the non-visible
workspaces. What you suggest is what I'm looking at for the actual fix
(with defaults for the non-visible workspaces) and corresponds to the EWMH
documentation (this is not surprising, the Gnome devs control the EWMH spec
these days). What worries me is that some programs may cache information,
when it will in fact be variable based on what workspaces are visible.

brandon s allbery kf8nh sine nomine associates
allbery.b@gmail.com ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Contributor

geekosaur commented Aug 11, 2016

On Thu, Aug 11, 2016 at 11:59 AM, Vincent Vinel notifications@github.com
wrote:

I'm not entirely sure what EWMH expects to be in _NET_WORKAREA, but
wouldn't it be possible just to store the workarea for each visible xmonad
workspace in the corresponding slot in _NET_WORKAREA, based on which
monitor that workspace is currently on ?

There are programs that break if you don't have values for the non-visible
workspaces. What you suggest is what I'm looking at for the actual fix
(with defaults for the non-visible workspaces) and corresponds to the EWMH
documentation (this is not surprising, the Gnome devs control the EWMH spec
these days). What worries me is that some programs may cache information,
when it will in fact be variable based on what workspaces are visible.

brandon s allbery kf8nh sine nomine associates
allbery.b@gmail.com ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

@geekosaur

This comment has been minimized.

Show comment
Hide comment
@geekosaur

geekosaur Aug 11, 2016

Contributor

On Thu, Aug 11, 2016 at 11:59 AM, Vincent Vinel notifications@github.com
wrote:

_NET_WORKAREA assumes the EWMH workspace model which does not map to
xmonad's workspace model.

I'm not entirely sure what EWMH expects to be in _NET_WORKAREA, but
wouldn't it be possible just to store the workarea for each visible xmonad
workspace in the corresponding slot in _NET_WORKAREA, based on which
monitor that workspace is currently on ?

Also, the real problem here is that, since dock visibility is per workspace
but placement is per screen, and workspaces are constrained to monitors,
the numbers end up changing a lot more than EWMH-using programs expect and
sometimes don't fully reflect what xmonad is actually doing.

brandon s allbery kf8nh sine nomine associates
allbery.b@gmail.com ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Contributor

geekosaur commented Aug 11, 2016

On Thu, Aug 11, 2016 at 11:59 AM, Vincent Vinel notifications@github.com
wrote:

_NET_WORKAREA assumes the EWMH workspace model which does not map to
xmonad's workspace model.

I'm not entirely sure what EWMH expects to be in _NET_WORKAREA, but
wouldn't it be possible just to store the workarea for each visible xmonad
workspace in the corresponding slot in _NET_WORKAREA, based on which
monitor that workspace is currently on ?

Also, the real problem here is that, since dock visibility is per workspace
but placement is per screen, and workspaces are constrained to monitors,
the numbers end up changing a lot more than EWMH-using programs expect and
sometimes don't fully reflect what xmonad is actually doing.

brandon s allbery kf8nh sine nomine associates
allbery.b@gmail.com ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

f1u77y added a commit to f1u77y/xmonad-contrib that referenced this issue Aug 30, 2016

set _NET_WORKAREA for each workspace
fixes xmonad/xmonad#42
fixes #73
note: there is no reliable way to determine index of a workspace, so
this can behave incorrectly with dynamic workspaces

f1u77y added a commit to f1u77y/xmonad-contrib that referenced this issue Aug 30, 2016

f1u77y added a commit to f1u77y/xmonad-contrib that referenced this issue Aug 30, 2016

thomasf added a commit to thomasf/xmonad-contrib that referenced this issue Nov 15, 2016

Temporary fix for qt/chrome menus/popups
xmonad#73

_NET_WORKAREA doesnt seem to affect anything I use daily...

thomasf added a commit to thomasf/xmonad-contrib that referenced this issue Nov 18, 2016

Temporary fix for qt/chrome menus/popups
xmonad#73

_NET_WORKAREA doesnt seem to affect anything I use daily...

thomasf added a commit to thomasf/xmonad-contrib that referenced this issue Dec 7, 2016

Temporary fix for qt/chrome menus/popups
xmonad#73

_NET_WORKAREA doesnt seem to affect anything I use daily...

thomasf added a commit to thomasf/xmonad-contrib that referenced this issue Dec 11, 2016

Temporary fix for qt/chrome menus/popups
xmonad#73

_NET_WORKAREA doesnt seem to affect anything I use daily...
@OakTwo

This comment has been minimized.

Show comment
Hide comment
@OakTwo

OakTwo Dec 13, 2016

A note for anyone else who loves xmonad, but only has the Haskell skills to cut and paste xmonad.hs code.

If you use geekosaur's workaround note that "workspacen" in the text above is the equivalent of "myWorkspaces" that you'll find in examples online, so replace "(length workspacen)" with "(length myWorkspaces)" and your xmonad.hs should recompile without errors.

Note this workaround currently works for me for both kdenlive and virtualbox, neither of which worked before. It's a little klunky at times with menus appearing separate from the original selection I clicked on, but it's easily usable, and I suspect this issue just means I need to read up on the values at the end of the line beginning "io".

For the developers, I hope this comment can be left in, if appropriate, so it keeps users with the same issue off your collective back.

OakTwo commented Dec 13, 2016

A note for anyone else who loves xmonad, but only has the Haskell skills to cut and paste xmonad.hs code.

If you use geekosaur's workaround note that "workspacen" in the text above is the equivalent of "myWorkspaces" that you'll find in examples online, so replace "(length workspacen)" with "(length myWorkspaces)" and your xmonad.hs should recompile without errors.

Note this workaround currently works for me for both kdenlive and virtualbox, neither of which worked before. It's a little klunky at times with menus appearing separate from the original selection I clicked on, but it's easily usable, and I suspect this issue just means I need to read up on the values at the end of the line beginning "io".

For the developers, I hope this comment can be left in, if appropriate, so it keeps users with the same issue off your collective back.

thomasf added a commit to thomasf/xmonad-contrib that referenced this issue Dec 21, 2016

Temporary fix for qt/chrome menus/popups
xmonad#73

_NET_WORKAREA doesnt seem to affect anything I use daily...

thomasf added a commit to thomasf/xmonad-contrib that referenced this issue Dec 27, 2016

Temporary fix for qt/chrome menus/popups
xmonad#73

_NET_WORKAREA doesnt seem to affect anything I use daily...

thomasf added a commit to thomasf/xmonad-contrib that referenced this issue Jan 10, 2017

Temporary fix for qt/chrome menus/popups
xmonad#73

_NET_WORKAREA doesnt seem to affect anything I use daily...

@pjones pjones self-assigned this Jan 11, 2017

@pjones pjones added this to the v0.13 milestone Jan 11, 2017

thomasf added a commit to thomasf/xmonad-contrib that referenced this issue Jan 16, 2017

Temporary fix for qt/chrome menus/popups
xmonad#73

_NET_WORKAREA doesnt seem to affect anything I use daily...
@pjones

This comment has been minimized.

Show comment
Hide comment
@pjones

pjones Feb 9, 2017

Contributor

Fixed in 0.13

Contributor

pjones commented Feb 9, 2017

Fixed in 0.13

@pjones pjones closed this Feb 9, 2017

@Narthorn

This comment has been minimized.

Show comment
Hide comment
@Narthorn

Narthorn Feb 10, 2017

Which commit fixes this?

Which commit fixes this?

@geekosaur

This comment has been minimized.

Show comment
Hide comment
@geekosaur

geekosaur Feb 10, 2017

Contributor

cd96de5
note that this requires an update to the X11 bindings, and the xmonad-contrib cabal file has not yet been updated to reflect that dependency.

Contributor

geekosaur commented Feb 10, 2017

cd96de5
note that this requires an update to the X11 bindings, and the xmonad-contrib cabal file has not yet been updated to reflect that dependency.

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