Skip to content
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

Issues with dual-screen setup and copyToAll #797

Closed
Robotix-00 opened this issue Jan 31, 2023 · 5 comments
Closed

Issues with dual-screen setup and copyToAll #797

Robotix-00 opened this issue Jan 31, 2023 · 5 comments

Comments

@Robotix-00
Copy link

Hi,
as stated in the title, if copyToAll from XMonad.Actions.CopyWindow (xmonad version 0.17.1) is used on a setup with two screens, it just doesnt work.
If the copyToAll command is called, the selected window moves to the other (inactive) screen. When trying to switch screens, the window moves to the new inactive screen. It seems to work somehow, since the window is always visible (just on the wrong screen) independend from to workspace. I tested it with my second screen turned off and it worked as expected.

Is there a way for the copied window to either stay on the screen it originated from or to always be on the active screen?

@geekosaur
Copy link
Contributor

copyToAll is a bit of a hack: it places the window id in every workspace, but doesn't and can't make an actual copy of the window. Therefore it gets rendered in the last position that X.O.windows places it. Looking at the code, I think the active workspace gets rendered first, which would mean the it would be placed in the last-rendered inactive but visible workspace. It's something of a bad fit with multi-monitor setups, in short.

@TheMC47
Copy link
Member

TheMC47 commented Jan 31, 2023

It's broken, and I don't think it's "fixable". I wanted to work on a replacement but didn't get to it yet.

@slotThe
Copy link
Member

slotThe commented Jan 31, 2023

I think

copyToAll […] doesn't and can't make an actual copy of the window.

is key here. AFAIK, this is something that would need to be done on the compositor side.

@Robotix-00
Copy link
Author

Uppon further testing it turns out, that this issue only applies to floating windows. Any "normal" window remains on the same screen. Is there some way of using this?

@geekosaur
Copy link
Contributor

geekosaur commented Jan 31, 2023

Probably not, unless https://hackage.haskell.org/package/xmonad-contrib-0.17.1/docs/XMonad-Layout-Monitor.html does what you want. Or you're willing to doIgnore the window, but then you can't focus or interact with it.

@slotThe slotThe closed this as completed Mar 5, 2023
LSLeary added a commit to LSLeary/xmonad that referenced this issue Mar 30, 2023
`windows` generates mappings one screen at a time, starting with the
current. Tracking the windows it's already generated mappings for,
it excludes them from the tiles under consideration, hence supporting
window duplication in a first-biased manner. This allows the current
screen to win against any contenders and keep duplicated tiles within
reach.

However, it neglects to extend this treatment to floats; they end up
mapped in a last-biased manner. Consequently, duplicated floats become
very slippery, escaping to any inactive screen they can. This change
rectifies that issue.

See: xmonad/xmonad-contrib#797
LSLeary added a commit to LSLeary/xmonad that referenced this issue Mar 30, 2023
`windows` generates mappings one screen at a time, starting with the
current. Tracking the windows it's already generated mappings for,
it excludes them from the tiles under consideration, hence supporting
window duplication in a first-biased manner. This allows the current
screen to win against any contenders and keep duplicated tiles within
reach.

However, it neglects to extend this treatment to floats; they end up
mapped in a last-biased manner. Consequently, duplicated floats become
very slippery, escaping to any inactive screen they can. This change
rectifies that issue.

See: xmonad/xmonad-contrib#797
LSLeary added a commit to LSLeary/xmonad that referenced this issue Apr 3, 2023
`windows` generates mappings one screen at a time, starting with the
current. Tracking the windows it's already generated mappings for,
it excludes them from the tiles under consideration, hence supporting
window duplication in a first-biased manner. This allows the current
screen to win against any contenders and keep duplicated tiles within
reach.

However, it neglects to extend this treatment to floats; they end up
mapped in a last-biased manner. Consequently, duplicated floats become
very slippery, escaping to any inactive screen they can. This change
rectifies that issue.

See: xmonad/xmonad-contrib#797
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants