On 29 Jun 2006 00:44:22 +0200, Dominik Vogt wrote: > > 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).
We are speaking about a user who knows what these Read and PipeRead commands do. I am not sure why you insist on automatic detection only. > * Commands calling or manipulating functions (AddToFunc, > DestroyFunc, calling a sub-function). Again, these may be pretty safe, a user should be able to specify NoGrab flag here. > * 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). The same with Exec (a user knows better). > * 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. I don't think a possible problem with NoGrab are that critical. If a user wants to get some nograb-related failures, he should be able to do so. There is no good reason the user has no relable way to do this currently: DefineFunc UpdateTitlePeriodically NoGrab + I PipeRead `printf "SetEnv DATE "; date +%Y-%m-%d` + I SendToModule FvwmButtons-Panel ChangeButton ... $[DATE] + I Schedule 20000 UpdateTitlePeriodically (And the Schedule time precision is not a problem here.) > AND > > 2) adds useful functionality (doubtful, considering the length of > the blacklist above). I believe the automatic detection is too complex and will add more bad than good. The explicit non-default NoGrab flag solves the problem. > > 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. Well, years ago I suggested to make "I" specifier optional in functions, because 90% of functions are immediate and there is no confusion if "I" is omitted. But there was no agreement. I would say that AllImmediate flag is redundant (may be a default). This may be discussed after 2.6.0. Regards, Mikhael.
