IconBox moves across screens

[afhp-2020]

The system has two randr screens, DVI-I-1 and DP-2. A single one-row iconbox was initially defined (under fvwm2):

Style * IconSize 32 32 32 32
Style * IconBox 0 -40 -1 -1, IconGrid 40 40

This definition has been adapted for fvwm3:

Style * IconBox screen DVI-I-1 0 -40 -1 -1, IconGrid 40 40

The windows are iconized with a Mouse definition calling Iconify, and restored according to the function

DestroyFunc DeiconifyAndRearrange
AddToFunc DeiconifyAndRearrange
+ C Iconify off
+ C All (CurrentDesk, Iconic) PlaceAgain Icon

Regardless of the above configuration, windows on DP-2 are always initially iconized according to the defined geometry, but on DP-2.

Moreover, the iconbox might jump screens.
Given windows w1s1, w2s1 on screen 1 (DVI) and w3s2 on screen 2 (DP):

• iconizing w3s2 puts the icon on DP
• then iconizing w2s1 puts its icon on DVI
• restoring w2s1 puts it back on DVI, and brings the icon for w3s2 to the iconbox on DVI
• on the other hand, with w1s1 and w2s1 iconized on DVI and w3s2 iconized on DP, restoring w3s2 will puts it back up on DP2 and move the icons for w1s1 and w2s1 onto DP2 as well.
• across these jumps, the geometry of the iconbox is respected.

With the explicit placement of the iconbox using the IconBox screen argument, all icons should always be put on DVI-I-1 regardless of the original window's screen.

I suspect that the jumping around part has to do with the parameters to DeiconifyAndRearrange but I haven't been able to find the Screen-related parameter to fix it.

[ThomasAdam]

Hi @afhp-2020,

Thanks for your bug report, and apologies it's taken me this long to respond.

Would you mind having a look at the ta/gh-40 branch? I've made quite a few changes to master since your filed this bug report, and equally, I've just pushed a commit to ta/gh-40 which might help the "wandering IconBox" problem you were seeing.

So thanks again, and let me know whether I've made things better, worse, or no change!

Thomas

[afhp-2020]

Hello Thomas,

Assuming I got the right version (I really don't "get" git, apparently -- removed the build directory completely, re-cloned from master, git checkout --track origin/ta/gh-40 and the latest commit in git log is indeed on that branch, dated 2020-05-04 regarding FindScreen.)

Earlier I modified button mappings so that icons would rearrange both when iconizing or restoring a window; the function is still

AddToFunc IconifyAndRearrange
+ C Iconify
+ C All (CurrentDesk, AnyScreen, Iconic) PlaceAgain Icon

No change : any window will iconize on the monitor it's opened.
When iconizing, the rearrange function will move the other icons (if any) to that screen. When restoring, it doesn't, the other icon(s) remain on the same monitor the icons group was at that time. (I just re-checked, AnyScreen doesn't seem to have any effect in this instance.)

[afhp-2020]

A slow and inelegant workaround that works in my specific use-case is to force the icons to the primary screen after the PlaceAgain:

+ C Iconify
+ C All (CurrentDesk, Iconic) PlaceAgain Icon
+ C All (CurrentDesk, Iconic) MoveToScreen $[monitor.primary]

It's slow and causes multiple visible redraws of the icons, but it might do the trick until this issue is cleared. No idea how good this workaround is beyond my own use, either, I suspect it's not particularly portable.

[ThomasAdam]

Hi @afhp-2020,

It's portable.

This is on my list to look at. Hopefully over the weekend.

Kindly,
Thomas

[ThomasAdam]

Hi @afhp-2020,

Sorry it's taken me so long to get around to looking at this.

So... some changes which I've made to this functionality -- see the ta/gh-40 branch for this:

• Actually look up the screen specified and use its coordinates;
• Style * IconBox screen <screen_name> .... will mean windows on <screen_name> will use the IconBox style for that screen.

I can't reproduce the moving icons behaviour -- but at the moment, if an iconified window is moved between screens, when that window is deiconified, the window will map back to the original screen it was on. Not sure if this behaviour should change or not.

[afhp-2020]

Hello Thomas,

No problem regarding the delay, I'm sure life is interfering :)

A clean build of gh-40 makes things kind of worse. Consistent with the new semantics you describe above, but with unexpected effects.

• Iconbox definition is unchanged:
  Style * IconBox screen $[monitor.primary] 0 -40 -1 -1, IconGrid 40 40
• Iconify function is back to its simplest expression:

DestroyFunc IconifyAndRearrange
AddToFunc IconifyAndRearrange
+ C Iconify
+ C All (CurrentDesk, AnyScreen, Iconic) PlaceAgain Icon

Now for the tests:

• Open two windows on primary screen
• Iconify them
  → The icons stack normally in the iconbox as defined
• Open a window on secondary screen (here, Emacs)
• Iconify it
  → Existing icons are restacked vertically to the left of the primary screen with a large gap (that's probably obeying a default iconbox/icongrid when not defined)
  → The icon for Emacs is nowhere to be seen (maybe near absolute 0,0 outside of primary ?)

Adding a second IconBox definition
Style * IconBox screen $[monitor.primary] 0 -40 -1 -1, IconBox screen DP-2 0 -40 -1 -1, IconGrid 40 40
then restarting Fvwm:

• Minimizing a window on DP-2 places the icon in the corresponding iconbox on DP-2 (expected, but not the behavior I'm after)
• Minimizing a window on primary places the icon in its proper place in the iconbox on primary
• Restoring the minimized icon on DP-2 places all existing icons in a (default ?) vertical stack on DP-2
• Minimizing a window on primary moves the icons belonging to that screen back to the iconbox on primary ; if there already is an icon on DP-2 it's moved to the vertical stack on DP-2 (sometimes at the top, sometimes further down with empty space above, I haven't searched for a pattern yet).
• (Restoring then) minimizing the window on DP-2 puts its icon in the iconbox on DP-2, and moves all other icons to the (default ?) vertical stack on DP-2.

One IconBox, no screen definition
Style * IconBox 0 -40 -1 -1, IconGrid 40 40
and restart:

• Same behavior as with two iconboxes, more or less (each screen obeys the iconbox definition even if it's not screen-specific, but icons move from screen to screen and in/out of their respective iconboxes).

Hope that's clear. I'm attaching the log regardless ; I'll try to come up with a more systematic/consistent test and/or a video if required.

I agree that a window should reopen on the original screen regardless of where its icon moved, that's just normal, expected behavior.

Regarding icons placement I suppose it's a bit more complex.

Just my opinion here but I would expect the following:

• if only one iconbox is defined without a screen specification it should apply to each screen (which it does, kind of)
• if only one iconbox is defined with a screen specification all icons should go there regardless of their screen of origin
• if multiple iconboxes are defined, each with its screen specification, that should be obeyed to the letter (windows on one screen iconify to that screen's iconbox)
• if multiple iconboxes are defined without any screen specification they should behave as in the original situation (overflow from one to the next) and apply to each screen (haven't tested this)
• If multiple iconboxes are defined each with a screen specification, a given screen's iconboxes should behave as overflow on that screen only
• In no case should icons be placed outside of defined iconboxes.

I hope this helps. I'm confident we'll get to the root of this one :)

[afhp-2020]

fvwm3-output.log.gh-40.txt

[ThomasAdam]

Hi @afhp-2020,

Thanks for the additional information. If you can take a video of what's going on, that will help.

Cheers,
Thomas

[afhp-2020]

Video sent by e-mail, too large for github.

[ThomasAdam]

I'm going to leave this as-is for the 1.0.0 release; moving the target milestone to post-1.0

[ThomasAdam]

I'm closing this for now.

[afhp-2020]

Hello Thomas, I'm intrigued by this closure. I rebuilt fvwm3 from a new git pull (previous directory got corrupted in an unrelated operation) a few hours ago, and the bug is still present. Have I missed a fix ?

…

On Mon, Oct 28, 2024 at 4:26 PM Thomas Adam ***@***.***> wrote: I'm closing this for now. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>