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

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.)

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.

Hi @afhp-2020,

It's portable.

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

Kindly,
Thomas

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.

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 :)

fvwm3-output.log.gh-40.txt

Hi @afhp-2020,

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

Cheers,
Thomas

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

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