Re: Grabbing and complex functions
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? 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. SCoTT. :)
Re: Grabbing and complex functions
Just to clarify ... 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. It doesn't matter if a function is invoked by Schedule or not - it can still fail to execute in either case. SCoTT.
Re: Grabbing and complex functions
On 6/28/06, Scott Smedley [EMAIL PROTECTED] 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? Hum.. I supose the warning/error should be generated. Reverting a function to a normal grab function would allow the abuse of NoGrab, which may be a source of false bugs.. But on the other hand it would make it more robust.. I can't decide on that.. 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. Yes, but on the other hand it would break the standard way of defining functions, which defeats the intuitive advantage.. I don't like the AllImmediate option :P.. Cheers, Renato SCoTT. :)
Re: Grabbing and complex functions
Scott Smedley a écrit : Hi Dominik et al, This post follows on from the previous ModuleListenOnly command which was getting a bit off-topic. As a hack/compromise, maybe we could modify AddToFunc to keep track of whether or not it uses a mouse modifier only then grab the X server, in execute_complex_function(). We discussed this a couple of years ago, and Olivier(?) suggested to allow functions without grabbing. The problem is that it is generally unpredictable which functions need to grab and which do not, and you can't do it on the fly because its too late then. I see. Well, there is at least 3 cases and not only 2 (grab / nograb). - Try to grab hard (for a long period of time) and give up if the grab fail. Current fvwm behavior, one problem (beside non execution) is that fvwm can be locked for a non negligible period of time. - Executing the function without trying to grab at all. You suggest to add such possibility. - Try to grab just 2 times (this is really fast). If the grab succeed everything is ok. If it fails execute the function any way. This is maybe a bit stronger/better than the previous case. My fvwm do that for any totally immediate function. This is not a perfect solution (but never cause me problems). But at the time we get our first discussion on this topic there was no consensus about how this should be expressed in term of fvwm configuration (or not at all). Of course you may want to have a 4th possibility: grab fast and do not execute if it fails. Olivier
Re: Grabbing and complex functions
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
Re: Grabbing and complex functions
Olivier Chapuis spake unto us the following wisdom: - Executing the function without trying to grab at all. You suggest to add such possibility. - Try to grab just 2 times (this is really fast). If the grab succeed everything is ok. If it fails execute the function any way. This is maybe a bit stronger/better than the previous case. My fvwm do that for any totally immediate function. This is not a perfect solution (but never cause me problems). But at the time we get our first discussion on this topic there was no consensus about how this should be expressed in term of fvwm configuration (or not at all). I think the previous is superior in at least some cases ... I have a config snippet (below) which I tried to use to flash the titlebar of urgent windows; it works OK, but causes focus weirdness (I think) due to the grabs on some slower machines. While the window is flashing, occasionally keystrokes will be lost when the coincide immediately with a colorset change. I think the first option above would alleviate this. DestroyFunc Flash AddToFunc Flash + I Style $0 Colorset 40 + I Schedule 750 1 Style $0 Colorset 1 + I Schedule 1500 1 Function Flash $0 Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 signature.asc Description: Digital signature
Re: ModuleListenOnly command
On Mon, Jun 26, 2006 at 01:50:30PM +1000, Scott Smedley wrote: Hi Dominik, That's just one purpose of the command. I was always fond of the idea to prototype or even implement modules as shell scripts. Yes, that would be cool. IMHO, I think it would be prudent to create bashlib (akin to perllib), instead of adding ModuleListenOnly command. Well, the new command is not a big deal. I just needed to add some code to close the fvwm_to_app pipes and modify some places to handle the situation that there is no fvwm_to_app pipe. To comment on the bashlib (which would be unusable for me, as I never use shells that are not either POSIX /bin/sh-compatible or zsh ;-) (Unless force to, of course): I don't have any idea how you could detect the size and byte order of a long (which is the base data type of a module message) from inside a shell script. Well, maybe fvwm could provide this information through the module's environment. But I suppose that should be a 2.6 feature? Um, you probably meant a post-2.6 feature? Yes, I think so, assuming that 2.6 would be released at a not too distant point in time. It is certainly possible to handle input from fvwm to the module in the script itself, but hard to guarantee that the input is processed in a timely fashion Why is that? Because shells were not made to handle input in that way. Look at my script for example. It would need two external triggers for its operations: * input from the fvwm pipe * a certain period of time has passed. Well, with zsh there is zselect that can trigger on both events at the same time (works like select()), but other than that I'd have to make something up with reading the fvwm pipe in a subshell (because it blocks the shell). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Grabbing and complex functions
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 2 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.
Re: Grabbing and complex functions
On 29 Jun 2006 00:24:50 +1000, Scott Smedley wrote: Just to clarify ... 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. It doesn't matter if a function is invoked by Schedule or not - it can still fail to execute in either case. Yes, but the problem of the failed re-Schedule is much more serious, because it is not a one-time failure (whenever the external grab occurs), but an infinite time of failures (non-happened function invocations). Regards, Mikhael.
