i have discerned the nature and possibly the cause (if not any solution)
of this problem...
it appears that whenever i use the following function:
AddToFunc "MoveRaise"
+ "I" Raise
+ "M" Move
attached to a Mouse binding with:
Mouse 1 A M Function MoveRaise
using it on a window leaves the mouse focus in a "problematic" state...
one which can cause a variety of bizarre behavior, including the
title not accepting updates within the focused window, and much
worse...
further investigation revealed that removing:
+ "M" Move
from the definition (which renders the function a redundant simple
Raise), removes all traces of the problem...
i suspected initially that my problems could be solved using some
variation of the "FP" (focus policy) Style definitions...
but experimentation with dozens of setting variations (mostly with
adding explicit negations that shouldn't have been set at all)
did nothing to alleviate the problem...
my default defintions are:
Style "*" FPEnterToFocus, FPLeaveToUnfocus, FPLenient
as i am an "old-school" stickler in wanting the "Focus Follows Mouse"
policy rigidly observed...
if anyone has any further suggestions to try (especially which would
solve the problem without disrupting the desired behavior) i'm open
to any ideas for experimentation...
B. Karhan
[EMAIL PROTECTED]
A little birdy told me that Benjamin Karhan said:
]
] i've noticed that fvwm 2.5.25 (and the recent snapshots, like 20080322
] and 20080330 specifically) exhibits a somewhat aggravating
] behavior with window event handling (not present in the 2.4.x branch
] definately).
]
] i kept putting off mentioning it because it didn't generate
] the types of things that would be useful for debugging
] (debug messages, core dumps, error messages, etc etc)
] but it's happened frequently enough (at least a few dozen times)
] that it seems to be a genuine "bug" somewhere...
]
] the problem can generally be described as "window events do not seem
] to take effect, on occasion, until one moves the mouse"...
] specific (non-fatal, but exasperating) examples of this include:
]
] - window title updates: title occasionally doesn't update
] after the normal control-code sequence... until one moves
] the mouse pointer
]
] - window closing: sometimes a window which was closed will
] remain (albeit blank and non-functional) until one again
] moves the mouse
]
] the most problematic example (and only once so far) i've seen is:
]
] - upon using the "animated window move" through a keyboard
] sequence, the window would not move until one moved the
] mouse, and after the window moved the mouse (although
] still present and "movable" around the screen) ceased to
] function as a "pointer" (i.e. no clicking registered,
] no focus changes, etc)
]
] i've built the above versions on CentOS4.6, CentOS 5.1, Slackware 11.0,
] and Solaris 10... and it SEEMS (although i could be wrong) to have
] effected them all...
]
] anyways... just wanted to bring it to everyone's attention...
] in the hopes that it may eventually warrant some fixing...
]
] B. Karhan
] [EMAIL PROTECTED]
]
