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

Multimonitor Support #26

Open
5 of 7 tasks
ibabushkin opened this issue Oct 12, 2016 · 1 comment
Open
5 of 7 tasks

Multimonitor Support #26

ibabushkin opened this issue Oct 12, 2016 · 1 comment

Comments

@ibabushkin
Copy link
Owner

ibabushkin commented Oct 12, 2016

This would be a pretty big change. For now, determine what the needed changes to existing code and infrastructure are.

  • wrap a screen's root window (together with some info on location), a tagset, vector of visible windows and screen geometry into a struct and place a vector of those in the Wm struct. Clarification: we still only have one screen/root window. Also, visible windows might also have to stay in our Wm object, I'm not sure.
  • allow for focus changes across screens
    • implement neighbour relationships across screens
  • interact with RandR
  • don't hide windows when monitors disappear
  • implement better visualization of tagset overlap (as in, provide the information necessary)
  • make redraws local to the affected screen(s)
ibabushkin added a commit that referenced this issue Nov 19, 2016
* now, redraws are triggered when necessary, as pointed out in #26
ibabushkin added a commit that referenced this issue Nov 20, 2016
…esses #26)

Now we get information on when two tagsets shown simultaneously overlap.
This is very useful since you probably are aware of the tags that are
*present* on a tag stack's top entry, but you can't easily know which of
those are actually shown. You have a guarantee, however, that they are
somewhere on screen, but they could have been claimed by a screen with a
lower index already. This information we now compute and output. This
also goes hand-in-hand with other changes around the logic of tagset
treatment. We need to be *very* careful to not blur the boundary between
*visible* and *current* tags on each screen.

This probably means that this implementation is buggy and has
unexpectedly rough corners in some places. For simple usecases, no bugs
are expected, however. Time to get fuzzing though.
ibabushkin added a commit that referenced this issue Nov 20, 2016
…esses #26)

Now we get information on when two tagsets shown simultaneously overlap.
This is very useful since you probably are aware of the tags that are
*present* on a tag stack's top entry, but you can't easily know which of
those are actually shown. You have a guarantee, however, that they are
somewhere on screen, but they could have been claimed by a screen with a
lower index already. This information we now compute and output. This
also goes hand-in-hand with other changes around the logic of tagset
treatment. We need to be *very* careful to not blur the boundary between
*visible* and *current* tags on each screen.

This probably means that this implementation is buggy and has
unexpectedly rough corners in some places. For simple usecases, no bugs
are expected, however. Time to get fuzzing though.
@ibabushkin
Copy link
Owner Author

Regarding local redraws - this is a quite annoying change, and only brings marginal benefits. This is not to be expected to be added soon ;)

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

No branches or pull requests

1 participant