FVWM: I need the FollowWindowList option in FvwmIconMan
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. When I study "FvwmWinList", then I read 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
Re: FVWM: I need the FollowWindowList option in FvwmIconMan
2012/1/18 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
FVWM: Want an alt-tab behaviour like KDE3
I want an alt-tab behaviour like KDE3: 1st) When I press +, I want a window list that does not move the mouse pointer. The mouse pointer is supposed to stay where it is. 2nd) I want to be able to select a window by pressing + (forward) and ++ (backward). When I press (+)+ with one hand and move the mouse with the other hand, then the mouse must not interfere with my keyboard action (selecting a window using (+)+). 3rd) When I press +, I optically want to see the windows in this list in the order in which they were recently focused, like WindowList already does. But: I want the second entry of the list to be selected when I open the list with Alt-Tab. The "CurrentAtEnd" option has the disadvantage that I do not optically see what I should see (or want to see). It disturbs my perception, because sometimes I *LOOK* onto the list if I'm searching for something that I do not get at one go. I have the right order in my mind, but the list shows me something different when I use the "CurrentAtEnd" option. It would be a great thing if FVWM were able to fulfill these requirements. But I'm not sure how could be the right approach to achieve this: - Make feature requests about creating new options for "WindowList"? - There should be an option like "preselectItem n", where I could set "n" to "2" to get a better solution than the "CurrentAtEnd" option. - There should be a "dontmovemouse" option to get a behaviour described under 1st). - There should be an "ignoremousemovement" option to get a behaviour described under 2nd). - Try to reverse engineer the Alt-Tab behaviour using FvwmIconMan? - Trouble is that I need to combine the "Key actions" of FvwmIconMan with the "FollowWindowList" option of "FvwmWinList" to get a list that does not move the mouse, that ignores mouse movement and that selects the second list entry (by using gotobutton or something like that) The bottleneck of my FvwmIconMan approach seems the be able to get a FollowWindowList behaviour. Does anyone have an idea how to get such a behaviour? If this means that I have to write a complicated algorithm then I would do this, but I need a good idea how to start this way. How likely is it that somebody enhances "WindowList" with the three options I described above? Does anyone has an idea if there could be a better way than my FvwmIconMan approach? At first glance, I see these modules: - WindowList - FvwmIconMan - FvwmWinList - FvwmWindowMenu Are there more like them that could be worth of thinking about using or abusing them? Any ideas are welcome. Thanks in advance Michael
Re: FVWM: I need the FollowWindowList option in FvwmIconMan
Thomas Adam wrote: > 2012/1/18 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
