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

FvwmIconMan must handle resolution settings better in per-monitor mode #396

Closed
ThomasAdam opened this issue Dec 31, 2020 · 0 comments · Fixed by #397
Closed

FvwmIconMan must handle resolution settings better in per-monitor mode #396

ThomasAdam opened this issue Dec 31, 2020 · 0 comments · Fixed by #397
Assignees
Labels
type:bug Something's broken! type:enhancement Augmenting an existing feature
Milestone

Comments

@ThomasAdam
Copy link
Member

When fvwm3 learned about per-monitor support, FvwmIconMan was never updated to take in to account that the resolution for desk, page, and screen would be different.

FvwmIconMan should change to realise that:

  • resolution screen should take an argument to clamp the resolution to a specific monitor;
  • resolution screen g should understand the concept of a global screen (as per resolution global currently).

This was found and discussed with jns on #fvwm IRC.

@ThomasAdam ThomasAdam added type:bug Something's broken! type:enhancement Augmenting an existing feature labels Dec 31, 2020
@ThomasAdam ThomasAdam added this to the 1.0.3 milestone Dec 31, 2020
@ThomasAdam ThomasAdam self-assigned this Dec 31, 2020
ThomasAdam added a commit that referenced this issue Dec 31, 2020
Monitors can already be referred to via geometry strings in the form:

    100x100+0-0@FOO

... where "FOO" can be an actual RandR monitor name, or a symbolic one,
as in:

  * g == global
  * p == primary
  * c == current

Expand this concept to allow these symbolic names when looking up
monitors in general.  This allows modules flexibility without having to
understand many of the internals of how fvwm structures monitors.

This change therefore makes `monitor_by_name` static to FScreen.c, and
introduces the replacement of `monitor_resolve_name` which handles both
a literal RandR name as well as symbolic ones.

Fixes #396
ThomasAdam added a commit that referenced this issue Dec 31, 2020
When Fvwm modules request a list of windows (or windows are sent to
modules via ConfigureNotify), the monitor name was never sent along,
which meant there were a few extra hoops needed to ascertain which
monitor a window is on.

Rather than forcing the user to resolve this, augment CONFIGARGS to
include the monitor name the window is on.  Currently only used by
FvwmIconMan, but this would help with FvwmPager in the future.

Fixes #396
ThomasAdam added a commit that referenced this issue Dec 31, 2020
When FvwmIconMan requests a list of windows to display, track which
monitors the windows are on.  This is used by FvwmIconMan when resolving
which resolution settings need applying.

Fixes #396
ThomasAdam added a commit that referenced this issue Dec 31, 2020
FvwmIconMan has always made an effort to track windows on different
screens.  With the introduction of RandR, as well as
`DesktopConfiguration per-monitor`, this broke how FvwmIconMan saw
different resolutions, especially for `screen` and `desk`.

This teaches FvwmIconMan about how to resolve its 'screen' resolution
better.  By default, the line:

    *FvwmIconMan: resolution screen

takes into account the *primary* screen.  If might not be the same as
the screen that FvwmIconMan is on, in which case the following can be
used:

    *FvwmIconMan: resolution screen c

The following two lines are equivalent:

    *FvwmIconMan: resolution screen g
    *FvwmIconMan: resolution global

Fixes #396
@ThomasAdam ThomasAdam linked a pull request Dec 31, 2020 that will close this issue
ThomasAdam added a commit that referenced this issue Dec 31, 2020
Monitors can already be referred to via geometry strings in the form:

    100x100+0-0@FOO

... where "FOO" can be an actual RandR monitor name, or a symbolic one,
as in:

  * g == global
  * p == primary
  * c == current

Expand this concept to allow these symbolic names when looking up
monitors in general.  This allows modules flexibility without having to
understand many of the internals of how fvwm structures monitors.

This change therefore makes `monitor_by_name` static to FScreen.c, and
introduces the replacement of `monitor_resolve_name` which handles both
a literal RandR name as well as symbolic ones.

Fixes #396
ThomasAdam added a commit that referenced this issue Dec 31, 2020
When Fvwm modules request a list of windows (or windows are sent to
modules via ConfigureNotify), the monitor name was never sent along,
which meant there were a few extra hoops needed to ascertain which
monitor a window is on.

Rather than forcing the user to resolve this, augment CONFIGARGS to
include the monitor name the window is on.  Currently only used by
FvwmIconMan, but this would help with FvwmPager in the future.

Fixes #396
ThomasAdam added a commit that referenced this issue Dec 31, 2020
When FvwmIconMan requests a list of windows to display, track which
monitors the windows are on.  This is used by FvwmIconMan when resolving
which resolution settings need applying.

Fixes #396
ThomasAdam added a commit that referenced this issue Dec 31, 2020
FvwmIconMan has always made an effort to track windows on different
screens.  With the introduction of RandR, as well as
`DesktopConfiguration per-monitor`, this broke how FvwmIconMan saw
different resolutions, especially for `screen` and `desk`.

This teaches FvwmIconMan about how to resolve its 'screen' resolution
better.  By default, the line:

    *FvwmIconMan: resolution screen

takes into account the *primary* screen.  If might not be the same as
the screen that FvwmIconMan is on, in which case the following can be
used:

    *FvwmIconMan: resolution screen c

The following two lines are equivalent:

    *FvwmIconMan: resolution screen g
    *FvwmIconMan: resolution global

Fixes #396
@ThomasAdam ThomasAdam moved this to Done in FVWM3 Sep 18, 2022
@ThomasAdam ThomasAdam added this to FVWM3 Sep 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Something's broken! type:enhancement Augmenting an existing feature
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant