Raise/lower when mouse enters/leaves a window

[kiezpro]

I guess this one’s simple, but I couldn’t figure it out.
I have FVWMButtons and gkrellm in the top left corner of my screen. I’d like to raise each one when the mouse pointer enters one of them, and I want the window that had the focus before to be re-focused & raised when the mouse pointer leaves them. For all other windows, I’d like to keep the default ClickToFocus behaviour that I use anyway.
This bit of my .fvwm2rc

Style "*" ClickToFocus Style "FvwmButtons" Sticky, MouseFocus Style "*gkrellm*" Sticky, MouseFocus
raises them accordingly, but doesnt give back the focus to the previous window when the pointer leaves them. So I assume that this is a job for FVWM Script, but my attempts failed so far. I guess that someone’s done this before and can just post a small code snippet here?
If you read the Gentoo Forums, you’ll see that I posted almost the exact same message there - sorry, but I didn’t get any feedback there.

[Nick_Fortune]

I didn’t see your post on the gentoo forums.

Interesting problem. Try using FvwmEvent to catch focus change and leave window events. Then you could call a funciton on focus change to set a variable to store the window id. Keep the previous one as well so you always have the IDs of the last two focussed windows.

On an exit-window event, call a function and check to see which window you left. If it’s FvwmButtons of gkrellm then you can use the previously focussed window id to raise and focus that window.

Needs a little work, but it should be doable

[thomasadam]

@Nick Fortune

Interesting problem. Try using FvwmEvent to catch focus change and leave window events. Then you could call a funciton on focus change to set a variable to store the window id. Keep the previous one as well so you always have the IDs of the last two focussed windows.

Not a variable – ugh! Use “State” as a means of identifying it. That was you cut out all of the piperead stuff you’d have to do as a result. For example, you could use the “enter_window” and “leave_window” events to dictate what’s what (note: I have not tested this):

DestroyModuleConfig FvwmEvent-foo: *
FvwmEvent-foo: Cmd Function
FvwmEvent-foo: enter_window FE-EnterWindow
FvwmEvent-foo: leave_window FE-LeaveWindow

So the above sets up FvwmEvent (using the alias of ‘FvwmEvent-foo’) to listen on the events specified. Note that you don’t necessarily want to use the event of focus_change as that could cause any number of race conditions. Moving on, the function for FE-EnterWindow might look something like this:

[code]
DestroyFunc FE-EnterWindow
AddToFunc FE-EnterWindow

• I ThisWindow (“gkrellm” AcceptsFocus CurrentPage) Raise
• I TestRc (Match) Any (CurrentPage AcceptsFocus) ThisWindow (“FvwmButtons”) Raise
• I TestRc (NoMatch) Break[/code]

Which for any window called either gkrellm or FvwmButtons Would raise both. So that when you next leave the windows, you might define FE-LeaveWindow as:

DestroyFunc FE-LeaveWindow
AddToFunc FE-LeaveWindow
+ I Prev ( !"gkrellm" !"FvwmButtons" AcceptsFocus) FlipFocus

Or somesuch. It’ll need a bit more work, but it should get you started. The other way of doing it, would be (on focus of either FvwmButtons or gkrellm) would be to set a State on the windows, and test for that state on WindowLeave – it would probably be slightly easier, too.

HTH,

– Thomas Adam

[Nick_Fortune]

@ThomasAdam

@Nick Fortune

Interesting problem. Try using FvwmEvent to catch focus change and leave window events. Then you could call a funciton on focus change to set a variable to store the window id. Keep the previous one as well so you always have the IDs of the last two focussed windows.

Not a variable – ugh! Use “State” as a means of identifying it. That was you cut out all of the piperead stuff you’d have to do as a result.

Why piperead? Surely something like this should work?

[code]DestroyFunc FuncRefocus
AddToFunc FuncRefocus

• I SetEnv window_to_be_focussed $[last_but_one_focus]
• I WindowId $[window_to_be_focussed] Focus
• I WindowId $[window_to_be_focussed] Raise
  [/code]

@ThomasAdam

So the above sets up FvwmEvent (using the alias of ‘FvwmEvent-foo’) to listen on the events specified. Note that you don’t necessarily want to use the event of focus_change as that could cause any number of race conditions.

If all you use the focus window event for is to set an environment variable (or state) and you trigger the re-focus on window exit there shouldn’t be any contention.

Or did I miss something obvious?

[thomasadam]

@Nick Fortune

If all you use the focus window event for is to set an environment variable (or state) and you trigger the re-focus on window exit there shouldn’t be any contention.

There might be – it depends on the focus policy you use (i.e. I suspect that ClickToFocus won’t cause many issues, but SloppyFocus might). Either way, passing FvwmEvent something like:

*Foo:  Delay 1

Should sort any nasties out.

– Thomas Adam

[kiezpro]

Many thanks to both of you! This is what it became for now:

DestroyModuleConfig FvwmEvent: *
*FvwmEvent: leave_window FE-LeaveWindow

DestroyFunc FE-LeaveWindow
AddToFunc FE-LeaveWindow

+ I TestRc (Match) \
    ThisWindow ("gkrellm|FvwmButtons|FvwmPager") \
    Prev ( !"gkrellm", !"FvwmButtons", !"FvwmPager", CurrentPage, AcceptsFocus) \
      FlipFocus

+ I TestRc (Match) \
      ThisWindow ("gkrellm|FvwmButtons|FvwmPager") \
        Lower

It gets confused when I scroll over to a different page and then put the mouse pointer over one of the windows in the list, and to my surprise FvwmEvent seems too slow to catch events when I move the mouse quickly, but otherwise it does exactly what I need.
It seems like the enter_window event doesn’t need to be handled in any special manner because those windows are set to MouseFocus anyway.