Focus policy upon iconify not predictable.

Configuration General Questions
1

TL;DR: My observations:

  • With style ClickToFocus, focus is automatically given to another window upon iconification.
  • But, regarding which window will be given focus upon iconifying, the behaviour seems unpredictable to me, as described below.
  • This behaviour seems to be not persistent across restarts.
  • This behaviour seems confusing after a page switch.

=========================

I’m using FVWM 2.6.5.

My complete .fvwm2rc:

Style * ClickToFocus

Key F2 WT N Iconify
Key F2 I  N Iconify

#Key n A 4 Exec exec dmenu_run
Key t A 4 Exec exec xterm

Mouse 1 I A Iconify

With the above config, here is what I did:

  • Open 3 windows

  • Press F2 3 times, all 3 windows got iconified (this impiles as the current window iconifies, focus goes to the next uniconified window)

  • Now I can rapidly press F2 and switch between ALL 3 windows. (6 key pressed for a full cycle)

  • restart fvwm, maybe a couple of restarts, or logout and start fresh.

  • Rapidly press F2, now I can only switch between 2 windows, the third window never gets deiconified.

But the above behaviour cannot be reliably reproduced.

Can anyone share some insights? Thanks!

2

I’ve searched through the forum and found some related posts. One theory is that these unpredictable beaviour is due to some ‘applets’ (such as xclock, pager, etc.) not being set as CirculateSkip. But in my test setup, there aren’t any ‘applet’ on the desktop, not even a pager.

I even thought about examining the source code and disable the stock ‘hand-out-focus-upon-iconify’ behaviour, so that I can implement my own algorithm in the configuration, without the interference from the built-in behaviour.

Could anyone help me out? This is really a confusing situation.

Thanks!

3

Another confusing behaviour:

  1. Frest start fvwm
  2. Open 3 windows, rapidly press F2 to cycle iconify/deiconify between all 3 of them, as described in the first post
  3. Switch to another page
  4. Open 3 windows, Now I cannot cycle through these 3 windows as in step 2. After iconifying the last window, focus goes nowhere.
  5. Go back to the previous page, now I cannot cycle through the previously opened 3 windows either.
    The behaviour is the same as in step 4.

It seems as if the window ring is ‘broken’. If I deiconify the first window then rapidly press F2, I can go no further than the 3rd window. If I deiconify the 3rd window first, I cannot switch to any window at all. (presumably because this is the end of the list since the ring looks like a list now)

4

I have felt that way too, altho perhaps for different reasons. Situations like when a window is closed, yet no other windows on the desktop received focus afterwards. Or where the focused window and the raised window are not exactly the same.

You are obviously looking for a consistent focus behavior. But you haven’t stated exactly what that desired behavior is. I mean, if the fvwm focus is slightly broken, perhaps the right question is how to fix it? And you shouldn’t have to hack the source code to do this.

In my own case, I have used FvwmEvent to ensure that no iconified window is ever focused. And to ensure that a no-focus situation never arises whilst there are focusable windows on the desktop.

PS. I too have observed that the order of the window ring is sometimes not preserved. In my case, non-iconified windows always retain their order. But the order of iconified windows in the Windowlist is sometimes unexpected. Didn’t give it much thought until now. Do you use the PlaceAgain command?

5

First, thank you very much for taking time to read my posts. :smiley:

In fact, I’ve already tweaked Iconify() in icons.c (It uses restore_focus_after_unmap() from focus.c to give focus to another window)
My tweak works to some extent, but obviously introduced a lot more problems since I’m not familliar with programming at all.

My desired behaviour is to give focus to “the next window” upon iconify, so that the focus would cycle through all windows.
In my setup I mapped F2 to iconify/de-iconify windows. In an ideal setup, I can press F2 in an rapid succession to cycle through all windows.

In fact, FVWM almost behaves like that, it’s just the inconsistencies that prevented it from working all the time. For example, it’s working fine after a fresh start, but after a page switch it began to act erratically.

And because of the inconsistencies, it’s very hard to repair the behaviour in the config. I guess any custom focus policy tweaks only happen after the built-in behaviour has completed. So if the build-in behaviour is unpredictable, the final result cannot stay persistent either.

Thanks for the tip! You reminded me of a new way to fix this. Maybe I can first de-focus all windows, then focus the one I want. I’ll take a look in my spare time.

I havent used that command before since I only started using fvwm for less than a week. Thanks for your various tips which are invaluable to a newbie like me. :slight_smile:

PS. I have been an xfce user for the past few years until the recent gtk±3.20 update broke nearly all the themes, focing me to find an alternative. :slight_smile:

Thanks again! :smiley:

6

Update:

I’m been searching through the man page for clues when I find the ‘FPReleaseFocus’ style. The man page states:

But my experiment shows that it is in fact controlling the behaviour upon iconifying windows, not closing windows.

I added this:

Style * !FPReleaseFocus

And miraculously, fvwm stopped giving out focus upon iconification. But it did not prevent fvwm from giving out focus upon closing windows, as stated in the man page.

With the built-in “give-out-focus-upon-iconify” behaviour finally disabled, I added my own focus policy tweak:

AddToFunc StartFunction I Module FvwmEvent
DestroyModuleConfig FvwmEvent: *
*FvwmEvent: Cmd Function
*FvwmEvent: iconify TransferFocus

DestroyFunc TransferFocus
AddToFunc TransferFocus
+ I Next (!Iconic, CurrentPage, AcceptsFocus, !Sticky) Focus
+ I TestRc (NoMatch) Next (CurrentPage, AcceptsFocus, !Sticky) Focus

I’ll report if it’s working as expected.

7

I finally managed to find someone who reported the same problem]https://www.mail-archive.com/fvwm@lists.math.uh.edu/msg15425.html[/url]
The author mentioned ‘switch pages’ which is exactly I’m experiencing, as described in post #3

So I tend to believe this could be a long-existing problem hiding in fvwm. It’s seldom discovered because most user would not use Style * ClickToFocus.
With FocusFollowsMouse or SloppyFocus, this problem becomes a lot less noticeable.

8

Having noticed that my iconic windows are sometimes outta order, I started to think about cmnds in my config that might be reordering iconic windows. But no answers yet.

I also came to fvwm from xfce. So if this is week one for you on fvwm, then you’re doing okay. But our desired focus policys are quite different, so I can’t be of more help on this…

9

Check out the difference between Focus and FlipFocus

http://fvwm.org/documentation/faq/#whats-the-difference-between-the-focus-and-flipfocus-commands

10

Fixed the problem by tweaking the options for my Windowlist menu.

11

This is what I use, and this is how most window managers transfer focus (I think)

AddToFunc StartFunction I Module FvwmEvent
DestroyModuleConfig FvwmEvent: *
# when iconify/close, focus prev active window
*FvwmEvent: iconify TransferFocus
*FvwmEvent: destroy_window TransferFocus
AddToFunc TransferFocus
 + I Prev (!Iconic, Raised, CurrentPage) Focus
 + I TestRc (!Match) All (!Iconic, CurrentPage) Focus

Together with

Style * !FPReleaseFocus
12

Found a little problem with it together with “quake” style drop down terminal managed by FVWM: when quake terminal shutters back, but I did started a program from it earlier and it’s window appeared, it gets defocused and some previous window in background gets focus. How I can tell it not to do that? Is there a window hierarchy tree match possible? I know little of X11 internals, so please don’t blame me much. :confused:
My current FVWM config (without this style, forget DeleteFocus commands - they’re my personal hack 8) ).

13

Personally I’m using this together with drop-down terminal managed by FVWM too,
and have no problems at all. Here is my drop-down terminal function:

[code]

Drop-down function

AddToFunc DropDown
+ I None ($1, CurrentDesk) Exec exec $0
+ I All ($1, Focused, !Maximized) ResizeMove $2 $3 $4 $5
+ I All ($1, CurrentDesk, Iconic) Iconify false
+ I TestRc (!Match) All ($1, !Focused) Raise
+ I TestRc (!Match) All ($1) Iconify true
+ I All ($1) FlipFocus

Drop-down terminal appearance

Style drop_down_term !Title, !Borders, !Icon, WindowListSkip, Sticky, !Closable, PositionPlacement 0 0, EWMHMaximizeIgnoreWorkingArea

Drop-down apps

Usage: DropDown ‘app_command <-flags>’ app_class width§ height§ position_x§ position_y§

Key F1 A N DropDown ‘urxvt -name drop_down_term -geometry 185x33’ drop_down_term 100 61 0 0

[/code]FVWM will show it when you press F1, if terminal is not hidden and is unfocused and covered by other windows, it will be raised and focused when you press F1.

14

It seems I found my “ideal” transfer focus FVWM function :slight_smile:,
after adding it, focus in FVWM works very well for me.
FVWM will focus previous active window (not icon!).
Here it is:

# Send focus
AddToFunc TransferFocus
        + I Prev (CurrentDesk, AcceptsFocus, !Iconic, !Overlapped) Focus
        + I TestRc (!Match) All Reverse UseStack (CurrentDesk, AcceptsFocus, !Iconic) Focus

Then add TransferFocus function to FvwmEvent module settings and FvwmEvent to StartFunction, then disable FVWM focus switch[code]

FvwmEvent (add actions to events)

Switch focus when switch desk or iconify/close window

*FirstEvent: iconify TransferFocus
*FirstEvent: destroy_window TransferFocus
*FirstEvent: new_desk ‘All Reverse UseStack (CurrentDesk, AcceptsFocus, !Iconic) Focus’

AddToFunc StartFunction
+ I Module FvwmEvent FirstEvent

Style * !FPReleaseFocus
[/code]