Clicking titlebars WITHOUT giving focus?

I’m using FVWM 2.5.14.

Here’s my function:

[code]DestroyFunc FuncTitleBarMoveOrLowerOrIconify
AddToFunc FuncTitleBarMoveOrLowerOrIconify

  • I MoveThreshold 0
  • M FlipFocus
  • M Raise
  • M FuncMove
  • C ThisWindow (Focused, !Overlapped) FuncIconify
  • C TestRc KeepRc FlipFocus
  • C TestRc Raise
  • H ThisWindow (Focused, !Overlapped) FuncLower
  • H TestRc KeepRc FlipFocus
  • H TestRc KeepRc Raise
  • H TestRc FuncMove[/code]
    FuncIconify, FuncMove, and FuncLower are just wrappers, there’s no problem with them. What this function is supposed to do (it’s bound to the titlebar, natch) is, if a window is not focused or overlapped by another window, give it focus and raise it, and, if you’re still holding down the mouse button, move it as if you’d pressed the mouse button and started dragging (as with “+M FuncMove”). If it’s already focused and not overlapped, iconify or lower it if you clicked or held the mouse button, respectively.
    It works perfectly for overlapped windows and also happens to work perfectly if a modifier key is held down, but otherwise FVWM invariably focuses windows when their titlebars are clicked, whether or not it’s been told to (even if mouse1 on the title bar is bound to nop with “Mouse 1 T A Nop”), This makes checking if the window you’re clicking on is unfocused impossible (unless you immediately flipfocus back to the previous window in the list, which goes beyond impractical).
    I hope there’s just some setting I’ve turned on or failed to turn off that causes this behavior, but It seems more likely that’s it’s FVWM making an assumption that, if I may humbly say so, is inappropriate for such a configurable WM to make (is stippled titlebars for sticky windows a sore subject to bring up?). Sorry if I sound a little frustrated, I this is actually one of the last problems I have with my improved config, a configuration that I highly to doubt could be replicated in any other contemporary window manager. Though if anyone’s interested in hearing more gripes about the problems I’ve managed to kludge I’ll gladly share. :wink:

[color=red]Edited by theBlackDragon:
–> Moved from Basic questions[/color]

You’re making commands up. :slight_smile: There’s no such command as “OverLapped”.
Perhaps you mean “Visible”?

What focus policy are you using? Look at some of the FP* styles –
perhaps in your case, FPFocusByFunction, and its negation.

With respect to stippled windows, I have a very unofficial and crappy
patch for that, which you will find reference to on these forums.

– Thomas Adam

Hey I didn’t know about it either till I realized that “Raised” wasn’t doing the job :smiley:. Check the manual, here’s the difference:
Raised: The entire window is visible
Visible: At least partially visible
!Overlapped: Completely “visible” within its own layer. Which is important so stay-on-top windows don’t muck up the works.

It’s not that I can’t live with stippled sticky windows, it’s that FVWM is the most configurable window manager I know of so it seems like hard coding anything that isn’t axiomatic for a window manager goes against its own philosophy (and even then it’s conceivable that nothing might be axiomatic, for example in the future maybe it’ll be “wrong” to assume that every window is rectangular, but you have to draw the line somewhere or else you’re making a window manager framework and not a window manager). But I don’t work on FVWM, just with it, so it’s not really up to me what its philosophy is; I’ll just complain when it becomes a problem since as I said I don’t think any other WM can do what I’ve become accustomed to with FVWM.

FVWM to Norfenstein: “I find your lack of faith disturbing.”
FPFocusByFunction is absolutely vital for my config but you pointed me toward FPClickDecorToFocus which is what needed to go. Sigh… she’s a harsh mistress, eh :slight_smile:

Thank you, a lot.

Right – I see it now. I had to search by exact case.

– Thomas Adam