search

lingnand / VIMonad

Bringing VIM philosophy to window management
vimonad.lynnard.me
70 stars 3 forks source link

Multi-Head Configuration Sometimes Causes Applications to Ignore DZen2 #3

Closed torrancew closed 9 years ago

torrancew commented 9 years ago

Occasionally (particularly in multi-head situations, and especially when switching from, eg, the native laptop display to just an external display), the dzen status bar(s) no longer influence window decorations on other applications. All programs act as if toggleStruts were not in effect, and hide the status bar(s).

lingnand commented 9 years ago

All programs acts as if toggleStruts were not in place...

This is a known issue that I've discussed with people on the official branch as well. Quick answer: it can't be easily solved. But, it won't affect your normal workflow if you follow these steps:

  1. in your xmonad.hs, define workspaces as

    , workspaces = take numberOfMonitors quickWorkspaceTags ++ [scratchWorkspaceTag]

    where numberOfMonitors is your number of monitors

  2. when VIMonad starts you'll notice each monitor takes a workspace, with its tag from quickWorkspaceTags in sequential order
  3. switch workspaces between monitors by pressing Mod-Ctrl-e
    • if you'd like, press it again to switch it back
  4. now the windows should respect your dzen bar properly

This solution works for me with 2 monitors; if you have more monitors just remember to switch between the workspaces before launching windows in any of them.

The cause for this whole problem, I suspect, has something to do with the start order of dzen2 and xmonad.

Occasionally (particularly in multi-head situations, and especially when switching from, eg, the native laptop display to just an external display)

I don't understand you completely here, but if you are looking for dzen bars to dynamically appear on your newly connected displays without a restart of VIMonad, that's currently still not possible. I've writen hooks that should trigger such change in times of display change, but it hasn't worked during my tests. Note that this is still an area where XMonad does poorly at. In such situations your new display wouldn't have dzen bars; but the old display would still keep the old status bar so it should be enough for most purposes.

However, if you're just mirroring your display from your laptop or you're using your external monitor as the only display, it shouldn't have any problem.

torrancew commented 9 years ago

@lynnard thanks! The last comment was in relation to swapping from using LVDS1 to an external monitor only - I often (but not always) see this cause the same bug. I will try the take numberOfMonitors fix, however, and get back to you.

If it's significant, the external monitor is a much larger resolution than the laptop display. Swapping back to LVDS1 rarely, if ever, causes this issue.

torrancew commented 9 years ago

Update: I can get this to happen pretty consistently when swapping displays and restarting xmonad, but have found that it typically only affects the workspace that was active when the displays switched. Deleting that workspace and creating a new one seems to work around the issue.

torrancew commented 9 years ago

I have 2 machines running VIMonad on arch, and can only reproduce this issue on one of them. I'm going to close this for now. If a clean re-install on that box doesn't solve things, I'll consider re-opening.

torrancew commented 9 years ago

(For clarity, the troublesome machine was upgraded "in-place" from a vanilla XMonad install, and I suspect some type of environmental pollution as the culprit here).