On Thu, Jun 29, 2006 at 12:12:21AM +1000, Scott Smedley wrote: > Hi Mikhael, > > > > DefineFunc would behave much like AddToFunc except for 3 differences: > > > 1. It would generate a warning message if the function already existed. > > > > This is bad. Configs should usually be re-read-able. Instead, it should > > silently apply DestroyFunc. In fact, DefineFunc (combining DestroyFunc > > and AddToFunc) is something I wanted to have for a long time. > > Good idea. > > > It is ok by me to add DefineFunc before 2.6.0, if it fixes issues. > > Particularly, will it fix reliability of (re-)Schedule? > > In my opinion, it's not Schedule that is broken/unreliable. _Any_ > function may fail to execute if the pointer is grabbed for ~1 second > at the time of execution. > > With the proposed modifications, "NoGrab" functions will not be prone, > to this failure. ie. if Schedule invokes a "NoGrab" function, it will > execute - even if the pointer is grabbed by some other app. > > This patch is available at: > > http://members.optusnet.com.au/scottsmedley/fvwm/defineFunc.patch > > Apply with: patch -p0 < defineFunc.patch > > A question about the implementation: > > Given this function > > DefineFunc MyFunc NoGrab > + I Echo hello world > + C Echo click > > should FVWM generate a warning (or error?) about using a non-I (immediate) > condition within a NoGrab function? Perhaps reverting the function to > a normal "Grab" function?
Well, it has all been discussed in that old thread.
The fact that fvwm needs to grab the pointer in some cases is
mostly unrelated to the action's type. Some complex functions
need to grab the pointer to make sure the user or other
applications does not interfere with function execution:
* The user might push or release a mouse button which causes
EnterNotify/LeaveNotify events that can confuse (immediate)
complex functions that raise or lower windows or fiddle with
the focus (or do other things that I can not think of).
We once tried to remove the grab, and functions using
Raise/Lower + WarpPointer + Focus could not do their job
anymore.
* What would commands like Move or Resize be good for without a
grab? Fvwm would freeze until the grab ends.
* The PointerWindow command could have very undesirable results
without a grab. For example, I have something like this in my
config:
Key d A SCM my_close
AddToFunc my_close
+ I Silent PointerWindow Close
If the pointer can be warped by an application during function
execution, a random window might be closed.
* You can not even know which commands need to run in case of
Read or PipeRead.
* What should fvwm do if a function consists of five commands and
the third command fails to grab the pointer because the complex
function did not bother to acquire the grab?
I agree that a failed grab can cause lots of problems. Hopefully
it's clear that many immediate functions may need the grab too.
But I have no idea how to decide if a certain function needs it or
not. The only way would be to write a whitelist of commands that
are okay to use in a "nograb" function. We would have to exclude
at least:
* Anything that can generate dynamic functions because it is
impossible to decide about whether a grab is needed (Read,
PipeRead, expanding variables or environment variables).
* Commands calling or manipulating functions (AddToFunc,
DestroyFunc, calling a sub-function).
* Any command that queries or manipulates the pointer (fvwm
freezes if it tries to access the pointer while a grab is
active).
* Any command that relies on EnterNotify or LeaveNotify events
(command may have unpredictable results).
* Any command that can not cope with the pointer being moved to
a different sceen.
* Any command that requires a window to operate on, as the user
is asked to select a window if none is selected yet. Currently,
34 commands are of that type (Move, Resize, WindowStyle, Close,
Focus, PlaceAgain, ...)
* Any other command that may grab the pointer itself (e.g. Exec).
* Conditional commands that use the HasPointer condition.
* Maybe all other conditional commands too.
* Possibly many more.
This ad-hoc blacklist already rules out many - if not most - of
the most important commands. I would agree to a "nograb" patch if
it
1) *enforces* proper operation, i.e. refuses to define
"nograb" functions that are potentially unsafe.
AND
2) adds useful functionality (doubtful, considering the length of
the blacklist above).
> Also, I took the liberty of adding an "AllImmediate" function option
> which allows the condition to be omitted. For example:
>
> DefineFunc MyFunc NoGrab AllImmediate
> + Echo hello
> + Echo world
>
> which I find much more intuitive. The "AllImmediate" flag indicates
> that all actions are "I" - immediately executed. How do others feel
> about this option? If there are objections I will happily remove it.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
