Can I make mouse focus not affect WindowList?

[giraffedata]

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.

[thomasadam]

@giraffedata

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?

It’s in the man page.

@fvwm manpage

   FlipFocus [NoWarp]
          Executes a Focus command as if the user had used the pointer to select the window.  This command alters the order of the WindowList in the same way as clicking in a window to focus, i.e. the target window is removed
          from the WindowList and placed at the start.  This command is recommended for use with the Direction command and in the function invoked from WindowList.

   Focus [NoWarp]
          Sets the keyboard focus to the selected window.  If the NoWarp argument is given, this is all it does.  Otherwise it also moves the viewport or window as needed to make the selected window visible.  This command does
          not automatically raise the window.  Does not warp the pointer into the selected window (see WarpToWindow function).  Does not de-iconify.  This command does not alter the order of the WindowList, it rotates the
          WindowList around so that the target window is at the start.

And this is the bit you want:

@fvwm manpage

   The Ring of Windows
          Fvwm stores windows in a ring internally.  Think of the focused window as a cursor on the current position in the ring.  The Next command and many other commands search forwards through the ring for a matching window,
          and Prev searches backwards.  The windows in the ring are either ordered by creation time (if the !FPSortWindowlistByFocus, NeverFocus or MouseFocus styles are used) or by the last time they had the focus.

– Thomas Adam

[giraffedata]

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.

[thomasadam]

@giraffedata

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.

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.

– Thomas Adam

[giraffedata]

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

[thomasadam]

@giraffedata

[…]

I can easily add something to CVS for this, but I am very reluctant to do so. I’ll think about it, and let you know. How’s that sound?

– Thomas Adam

[giraffedata]

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

[giraffedata]

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.