FVWM: I need the FollowWindowList option in FvwmIconMan

[Michael Großer]

Hi!

I try to reverse engineer the Alt-Tab behaviour of KDE3.
I want to find out if FvwmIconMan could be the right tool
for this.

*FvwmWinList: FollowWindowList
Specifies that FvwmWinList will keep its list in the
same order as fvwm. This is the order displayed by the
"WindowList NoDeskSort" fvwm command. This is not the
default as it is more visually disturbing when the
focus changes.

Since FvwmIconMan is supposed to replace FvwmWinList,
how can I achieve the FollowWindowList behaviour of
FvwmWinList with FvwmIconMan?

Best regards,
Michael Großer

[Thomas Adam]

Post by Michael Großer
Since FvwmIconMan is supposed to replace FvwmWinList,
how can I achieve the FollowWindowList behaviour of
FvwmWinList with FvwmIconMan?

Because "replace" does not mean carbon copy. It's not a like-for-like
comparison, and deprecation does not mean a complete replacement
either. Do not make me repeat yet again the reasoning behind this.

You can't achieve the ordering that you're after without FvwmIconMan
being patched, which would also affect the SortedWeight options, etc.,
as well as the ability for multiple FvwmIconMan managers managing
different lists.

It's not even clear whether this feature will make it across to
FvwmIconMan -- in the first instance, most definitely not.

-- Thomas Adam

[Michael Großer]

Post by Thomas Adam

Post by Michael Großer
Since FvwmIconMan is supposed to replace FvwmWinList,
how can I achieve the FollowWindowList behaviour of
FvwmWinList with FvwmIconMan?

Because "replace" does not mean carbon copy. It's not a like-for-like
comparison, and deprecation does not mean a complete replacement
either. Do not make me repeat yet again the reasoning behind this.
You can't achieve the ordering that you're after without FvwmIconMan
being patched, which would also affect the SortedWeight options, etc.,
as well as the ability for multiple FvwmIconMan managers managing
different lists.
It's not even clear whether this feature will make it across to
FvwmIconMan -- in the first instance, most definitely not.
-- Thomas Adam

Is there a way to write a patch or an option or something else
that uses the SortedWeight options to keep the list in the
same order as FVWM in realtime? Some sort of function or script
could determine the current FVWM order and set the SortedWeight
options in a way that they reflect the FVWM order.

It would be a dirty approach, but it could have a useful effect:
It could make "FvwmIconMan" be a better alternative to "WindowList".
It would make FVWM more flexible and more powerful.

I mean, when I use FvwmIconMan in a transient mode, I don't
need features like SortedWeight or multiple FvwmIconMan managers.
It would not harm if some kind of FollowWindowList option would
disable other features while the user wants to use this feature
in this use case. The user could use both kinds of features
simultaneously just by using multiple instances of FvwmIconMan
anyway, if someone wants this...

Just trying to find a solution ;-)
Michael

[Thomas Adam]

Post by Michael Großer

Post by Thomas Adam

Post by Michael Großer
Since FvwmIconMan is supposed to replace FvwmWinList,
how can I achieve the FollowWindowList behaviour of
FvwmWinList with FvwmIconMan?

Because "replace" does not mean carbon copy. It's not a like-for-like
comparison, and deprecation does not mean a complete replacement
either. Do not make me repeat yet again the reasoning behind this.
You can't achieve the ordering that you're after without FvwmIconMan
being patched, which would also affect the SortedWeight options, etc.,
as well as the ability for multiple FvwmIconMan managers managing
different lists.
It's not even clear whether this feature will make it across to
FvwmIconMan -- in the first instance, most definitely not.
-- Thomas Adam

Is there a way to write a patch or an option or something else
that uses the SortedWeight options to keep the list in the
same order as FVWM in realtime? Some sort of function or script

No. That's not what I want at all.

At the moment, we have a couple of user-perceptive disconnects -- that is,
functionality which makes sense to me, but no one else, and that's bad.

1. The window list [1] which FVWM maintains, which can be in either focus
order, or creation time (see [!]FPSortWindowListByFocus).

2. Sort options to WindowList which can alter the display of where the window
in the WindowList

3. Sort options to different modules (Fvwm{IconMan,WindowMenu,WinList} which
affect the display of windows in those lists.

It's really point 1., above, which causes the most confusion, because
there's no real relationship between the internal list of windows with
!FPSortWindowListByFocus and the display of windows in WindowList -- because
FlipFocus will reorder the list for both (i.e., in terms of where it is in
window_list, and then displayed in the WindowList). Point 1., though will
affect the way conditional commands work, which is why they're reorderable
with the focus policy.

So to say you want "FollowWindowList" doesn't make much sense, because the
WindowList can display windows in anyway it likes -- of course, I *know*
what that option means, but really, what this all boils down to is taking
the order of how the windows are linked together and dumping that out as the
order.

And I think that whilst it's nice to have it linked to the focus model, it
should instead be more configurable. Because as soon as we have that, the
various bits of code which display the list of windows can just use it.

This then doesn't mean adding more and more options.

-- Thomas Adam

[1] You need to understand the difference between the "window list", which
is the linked list of windows which FVWM maintains to link the windows
together, and the WindowList command which is displaying those windows, in
any order one choses; unfortunately in the context of this email it makes it
confusing to know which ones I'm referring to. :P