I use SloppyFocus. When I focus a window by moving the mouse to it, the list of windows subsequently displayed by WindowList is rotated so the focused window is at the top.
This really messes me up. Is there a way to make focusing a window by moving the mouse to it not affect WindowList?
I don’t know what sort of use habits would make that rotation useful, but I find it useful for WindowList to be in most-recently-used order and I have most of the actions I use to focus a window set up to do a FlipFocus so that is the case. But focus one window by moving the mouse to it, and it’s all gone.
Thanks for taking the time to quote the relevant parts of the man page, but I actually read them all multiple times before posting, and did lots of experimentation to try to resolve ambiguities in them, and finally concluded either the manual is wrong or I am missing some interpretation of them. The manual does not seem to to match my experience. So I still don’t have an answer to my question.
One problem I had is that the relationship between the described internal ring of windows and the WindowList menu is not stated. There’s evidence that they’re related and evidence that they are not.
Another slight ambiguity is reference to something called “the WindowList”. It’s not defined. But I know there is a command called WindowList and it has a menu that is a list of windows, so it’s easy to assume a connection there.
Another ambiguity is that a ring has order, but generally has no beginning and end. But since the manual invokes a concept of a cursor, one might interpret that as the beginning of the ring. Rotating the window therefore might be considered changing the order of the ring or not. The WindowList menu has an obvious beginning and end, since it displays as a linear stack. Maybe the top of the list is supposed to be that cursor; maybe not.
The The Ring Of Windows section mentions that this ring has direction, too, but in describing the order (creation time or focus time) doesn’t say which direction is which.
I did not find anything in the manual telling what effect moving the mouse to focus has on the ring. My experiments show it’s the same as a Focus command.
Finally, by any definition of terms I can think of, if “the WindowList” and the “internal ring” are related at all, the description under “Ring Of Windows” contradicts the description of the Focus command, because using Focus appears to make the order of the ring neither the order of focus nor order of creation.
My point in all of the above is just that a) there is room for improvement in the manual (which might avoid questions like mine or at least make them easier to ask); and b) I still don’t know if I can make mouse focus not affect relevant window ordering. “No” is looking more likely, but it does seem like a natural capability for FVWM to have.
The ring of window is internally re-ordered depending on focus – and it’s this ring which is used by conditional commands, which is why you’re able to say Prev (…) and Next (…) and have them defined in the order of last focused. The creation time aspect comes in to play as previously described.
As far as this ring is affected, this will always be the case when focus happens.
That’s not going to change.
Your other confusions are… well, your own, from what I can tell.
“Your confusions are your own” is a strange statement – sounds like a tautology. Anyway, it looks like I’m not going to get any better understanding of the window list/ring/WindowList/order thing from you, but I’m pretty sure now I can’t just put something in my configuration file to make mouse-movement-induced focus not affect ordering of windows.
I’ll have a look at the code to see if I can add that ability; focus switching behavior has been a constant irritation for me for many years and it’s time to try to do something about it.
In fact, I’ve already done something: I did the investigation to find out how the ordering works (until now, it just seemed to get scrambled at random times). Based on that, I could just switch to ClicktoFocus; at the cost of more laborious mouse work, that keeps my window order more usable.
That would be nice. And if you know how to do it and just don’t want to distribute it to all your fans, you could just tell me and save me a lot of work. I don’t mind running local modifications (in fact, I see I already have one for fvwm: to make it use an FVWM_DATADIR environment variable).
In trying to implement this, I recompiled from what I thought was the same source code and the objectionable window list rotating behavior is gone. Now, when I set focus by moving the mouse to a window, Fvwm plucks the newly focused window from whereever it is in the list and puts it at the top, as with a FlipFocus command.
This may be good enough. The problem would be that if I happen to drag my mouse over some other window on the way to its target, that other window would end up among my most recently used windows at the top of the list. So I may ultimately try to make mouse focus simply not affect the window list, but I am going to see how this works out first.