Two PanFrame/EdgeScroll issues. (Regression cf. FVWM2.)

[taobert]

Thanks for reporting your bug here! The following template will help with
giving as much information as possible so that it's easier to diagnose and
fix.

Upfront Information

Please provide the following information by running the command and providing
the output.

• Fvwm3 version (run: fvwm3 --version)
  current master:

# fvwm3 --version|head -n2
fvwm3 1.0.3 (1.0.2-58-g5114d153)
with support for:  ReadLine, PNG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS

• Linux distribution or BSD name/version
  Debian Sid

Linux draven 5.10.0-3-amd64 #1 SMP Debian 5.10.13-1 (2021-02-06) x86_64 GNU/Linux

Expected Behaviour

Mousing off the edge of a page should place the mouse cursor at the near edge of the adjacent page.

Actual Behaviour

Issue 1: With multiple monitors, mousing off the edge of a page places the cursor at the boundry between two monitors.
Issue 2: It's possible to make FVWM3 confused about where PanFrames should be, breaking mouse scrolling.

Steps to Reproduce

Issue 1

I have two monitors side by side:

xrandr --output DP-0 --mode 1680x1050 --pos 0x0
xrandr --output DVI-D-0 --mode 1680x1050 --right-of DP-0

Using the attached MWE config file, with FVWM2, edge scrolling works correctly:
When i move past the right edge of the right-hand monitor (DVI-D-0)
the mouse pointer is now at the left edge of the left-hand monitor (DP-0).
In FVWM3 however, scrolling off the right edge of DVI-D-0 places
the mouse pointer at the left edge of DP-0 (edit: i mean DVI-D-0) (the right-hand monitor).
This means that when i accidentally push past the edge resistance,
i need to go much further back to get to where i wanted to be.

When i mock up screens arranged vertically:

xrandr --output DVI-D-0 --below DP-0

and restart FVWM, FVWM2 again behaves correctly, but interestingly,
FVWM3 gets it correct when moving down, but when moving up from DP-0,
the mouse pointer is (incorrectly) at the bottom of DP-0.

Issue 2

During this testing, i've also found a second issue,
which is possibly subordinate to the first, and/or possibly a duplicate of #381:
Mouse page scrolling can be broken in certain circumstances,
possibly because PanFrames get misplaced.

After orienting the monitors horizontally again:

xrandr --output DVI-D-0 --right-of DP-0

and restarting (now on page 0x0, on DP-0), the log shows no is_pan_frame messages at the left of DP-0,
or the top of DP-0 or DVI-D-0.
Mousing up and down in DP-0 scrolls pages correctly,
and shows the PanFrames at the correct place (between pages).
However, if i scroll down on DP-0 and then back up on DVI-D-0, now although i'm on page 0x0,
the log shows that there is a PanFrame at the top of both screens, and not at the bottom.
This means that i'm unable to scroll back to the lower page with the mouse.
Likewise, mousing right from page 0x0 to 1x0 and then back again,
causes a PanFrame to be at the LHS of DP-0, and no PanFrame to be at the RHS of DVI-D-0,
so now page scrolling to the right doesn't work.
Using either of these to break scrolling in one direction,
corrects the PanFrame placement in the orthogonal direction,
and re-enables scrolling in that direction.

Changing page with the keyboard in the direction that the scrolling is stuck
(Alt-[hjkl] in the provided config) puts the PanFrame back where it should be.
As with #381, the mouse will still scroll if it's dragging a window,
despite the PanFrame apparently not being at the page boundary (according to the logfile).

Note in the attached log that after we mouse down on DP-0 (1615083799.770354)
and up on DVI-D-0 (1615083806.146475), we're back on page 0x0.
Mousing to the bottom of the screen no longer produces messages.
Mousing to the top of the screen produces handled paging for ... (0).
Am i correct in assuming the (1) or (0) in handled paging messages is success or failure?

• Does the problem also happen with Fvwm2?
  No.

Does Fvwm3 crash?

No.

Extra Information

fvwm3-output.log.txt
config.mwe.txt

[ThomasAdam]

Hi @taobert

Thanks for the bug report. I really appreciate the level of detail you've provided, thanks for that.

Please can you take a look at the ta/gh-459 branch and tell me if this fixes the issue for you? I've played with it most of the day and couldn't get it to break.

[taobert]

Looks good.
I'll complain if i find anything wrong later...:)
Thanks again.

[ThomasAdam]

Hi @taobert

Thanks -- let me know either way, and if things look good, I'll merge this tomorrow.

If you can, could you check how DesktopConfiguration per-monitor holds up with this change?

[taobert]

I'll have to read up on how DesktopConfiguration per-monitor is suposed to work,
but it's not behaving in a manor that i find intuitive or useful.
I'll get back to you.

[ThomasAdam]

I'm merging this change in -- been using it every day for the past week.

Any problems, please open a separate issue.

[taobert]

Yes, i'm sorry for not replying earlier, i've come down with a bout of real life.
As you determined, the panframes seem to be functioning correctly with DesktopConfiguration per-monitor.

Business arising

However, FWIW, i think the documentation for DesktopConfiguration per-monitor is pretty inadequate.
I wasted a day trying to figure out why per-monitor behaved so weirdly before i discovered *FvwmPager: Monitor RandRName.
Using an un-Monitor-ed pager suggests that per-monitor is implemented using half-pages of the same desktop,
with windows being shuffled about, rather than "each RandR monitor [having] a separate copy of desktops" (per man fvwm3).
Also, the rather coy suggestion in man FvwmPager that *FvwmPager: Monitor RandRName
"is especially meaningful when the DesktopConfiguration command is set to per-monitor" is not especially meaningful.
It would be better to point out (in both places) that this is mandatory if per-monitor is to have any semblance if sensible behaviour.

Even with *FvwmPager: Monitor set, there are some awkward quirks:

• Dragging a window within one page of the pager can move it onto the other monitor
  (despite this ostensibly being another page on another desk on another monitor).
• Dragging a window to the "wrong" side of another page can cause it to disappear entirely.
• By panning the viewport (right click and drag on the pager) so that it spans pages,
  it's possible to make windows belonging to one monitor appear on the other
  (despite the owner's pager showing that it hasn't moved).

Additionally, the fact that separate pagers are required for each screen makes it convoluted to
intuitively shift windows between different screens' desks,
as they need to be dragged across the screen boundary to change screens/desks.
Allowing windows to be dragged into a pager (the converse of dragging a window out of the pager) would mitigate this,
and would be valuable even for people using DesktopConfiguration global.
It'd also be nice if a single pager could display all the desktops of all the monitors.

Some asides

The advice here to put DesktopConfiguration per-monitor at the top is somewhat surprising,
as IIRC most things in the config file are unordered.
I didn't see a particular difference whether it was above or below Module FvwmPager, so perhaps this is no longer relevant,
but (i feel, if it's possible) it'd be better if the order of this didn't matter.
If it isn't possible, this needs to be mentioned in the man page.

dev-docs/TODO.md has an unchecked box for PanWindows per-monitor inhibit moving windows across screen boundaries
however this works for me. (Maybe this is fixed since #285.)

[ThomasAdam]

Yes, i'm sorry for not replying earlier, i've come down with a bout of real life.

That's OK. Hope all is well.

As you determined, the panframes seem to be functioning correctly with DesktopConfiguration per-monitor.

Excellent.

However, FWIW, i think the documentation for DesktopConfiguration per-monitor is pretty inadequate.

Patches welcome if you feel the documentation needs improving.

I wasted a day trying to figure out why per-monitor behaved so weirdly before i discovered *FvwmPager: Monitor RandRName.

The two things are decoupled from one another -- DesktopConfiguration per-monitor sets however many desks have been defined via DesktopName per RandR monitor, while FvwmPager gives an overview of the desks/pages. By default, FvwmPager has always shown the entire root window in one go.

I agree that it can be confusing if you have a FvwmPager showing all monitors and switching pages. One approach we could take here is to detect when the pager is showing everything across monitors and draw in the monitor boundaries on the pager window -- in much the same way that we do for the boundaries between desks/pages. The only downside here is that unless you've configured FvwmPager to match your RandR layout, then it might look odd.

What I am loathe to do is make FvwmPager behave differently when DesktopConfiguration per-monitor is set without configuration. I know it means the user has to make that leap of configuration -- if you have some suggestions around how best to make this easier, I'm very keen to hear them. Bear in mind it's not just FvwmPager, there are other modules which track monitors (FvwmButtons, FvwmIconMan) -- how do we deal with those?

Using an un-Monitor-ed pager suggests that per-monitor is implemented using half-pages of the same desktop,

It might look like that, but only because it's drawing all windows on the root window across monitors. Per my earlier suggestion, we could add in monitor boundaries to the pager. Or do something else, if you can suggest something?

with windows being shuffled about, rather than "each RandR monitor [having] a separate copy of desktops" (per man fvwm3).
Also, the rather coy suggestion in man FvwmPager that *FvwmPager: Monitor RandRName
"is especially meaningful when the DesktopConfiguration command is set to per-monitor" is not especially meaningful.
It would be better to point out (in both places) that this is mandatory if per-monitor is to have any semblance if sensible behaviour.

If you spend time on the documentation, I'd be very happy to review it if you feel it's not descriptive enough.

Even with *FvwmPager: Monitor set, there are some awkward quirks:

• Dragging a window within one page of the pager can move it onto the other monitor
  (despite this ostensibly being another page on another desk on another monitor).

See: #198

• Dragging a window to the "wrong" side of another page can cause it to disappear entirely.

See #198

• By panning the viewport (right click and drag on the pager) so that it spans pages,
  it's possible to make windows belonging to one monitor appear on the other
  (despite the owner's pager showing that it hasn't moved).

Yes -- there's not much I can do about this, unfortunately. Much like pages, the windows between them are merely moved out of the way when the root window is dragged. This works fine when desktops aren't per-monitor, but things look awkward when per-monitor mode is in use.

Additionally, the fact that separate pagers are required for each screen makes it convoluted to

Well, they're not required per-se, it's depends whether you set DesktopSize.

intuitively shift windows between different screens' desks,
as they need to be dragged across the screen boundary to change screens/desks.

Yeah -- again, we could maybe look at using some sort of screen resistance.

Allowing windows to be dragged into a pager (the converse of dragging a window out of the pager) would mitigate this,
and would be valuable even for people using DesktopConfiguration global.
It'd also be nice if a single pager could display all the desktops of all the monitors.

See above; I agree.

Some asides

The advice here to put DesktopConfiguration per-monitor at the top is somewhat surprising,
as IIRC most things in the config file are unordered.

They're by no means unordered (see: https://www.mail-archive.com/fvwm@lists.math.uh.edu/msg16494.html), however in the case of DesktopConfiguration per-monitor being required near the top, I was checking to see if there was an ordering problem. I suspect it is fixed now.

I didn't see a particular difference whether it was above or below Module FvwmPager, so perhaps this is no longer relevant,
but (i feel, if it's possible) it'd be better if the order of this didn't matter.

I don't think it does now.

dev-docs/TODO.md has an unchecked box for PanWindows per-monitor inhibit moving windows across screen boundaries
however this works for me. (Maybe this is fixed since #285.)

Thanks, will update.