Open afhp-2020 opened 4 years ago
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:
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:
One IconBox, no screen definition
Style * IconBox 0 -40 -1 -1, IconGrid 40 40
and restart:
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:
I hope this helps. I'm confident we'll get to the root of this one :)
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
The system has two randr screens, DVI-I-1 and DP-2. A single one-row iconbox was initially defined (under fvwm2):
This definition has been adapted for fvwm3:
The windows are iconized with a
Mouse
definition callingIconify
, and restored according to the functionRegardless 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):
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 theScreen
-related parameter to fix it.