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: ModuleListenOnly command
Hi Dominik, Are you enjoying the World Cup? Two reasons: (1) Schedule is an unreliable hack and (2) this starts a shell every 15 seconds and my goal was to waste as little cpu as possible (as it interferes with certain time-critical applications - okay - games). Hehe. :) Re: (2) From some rudimentry tests I've performed on my Linux laptop, using 'sh' adds little overhead. Your CPU usage is going to be swamped by 'ps'. 'ps' performs ~1000 system calls [1], whereas 'sh' performs 116 system calls [2] - an 11% overhead. Plus you've got a 'sort' in there which is nearly another 100 system calls. 'sh' isn't going to take any longer as the number of processes increases, but 'ps' 'sort' will. I realise the number of system calls isn't a direct measurement of CPU usage, but it's a pretty good metric for the issues you're considering here. In short, I'm not sure adding a new builtin command to Fvwm to speedup an arcane situation (by _at best_ 10%) is really worth it, IMHO. I am prepared to write FvwmButtonsUpdater for you (using perllib) if you need the extra 10% performance, but I can't promise how much faster it will be. Re: (1) Having just looked into how Schedule execute_complex_function() work, I'm not prepared to blame Schedule just yet. In my opinion, I don't think FVWM should grab the X server everytime it executes a complex function. I realise it's necessary when the function references the Motion/Click/Hold/Double modifiers but in the majority of cases, most user functions will just use Immediate. [3] This makes me think it would have been nice to separate AddToFunc into 2 separate commands - AddToMouseFunc AddToFunc. Where AddToMouseFunc would permit modifiers, AddToFunc would _always_ assume an Immediate modifier. 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(). Thoughts? SCoTT. :) [1] strace -o /tmp/o /bin/ps -A --format %C %P %c ! /tmp/ps.out wc -l /tmp/o [2] strace -o /tmp/o sh -c : ; wc -l /tmp/o [3] I've no data to support this, except for my own config where I rarely use a modifier other than Immediate.
Re: ModuleListenOnly command
Dominik Vogt wrote: On Sun, Jun 25, 2006 at 07:18:30PM +1000, Scott Smedley wrote: Having just looked into how Schedule execute_complex_function() work, I'm not prepared to blame Schedule just yet. In my opinion, I don't think FVWM should grab the X server everytime it executes a complex function. I realise it's necessary when the function references the Motion/Click/Hold/Double modifiers but in the majority of cases, most user functions will just use Immediate. [3] Why must the entire server be grabbed to track mouse movement? Why not grab only the mouse? Also, I use modifiers to have mouse clicks and mouse drags on window frames do different things. (Drag to resize/move, click to raise/lower) Is this why other windows freeze when resizing a window? This makes me think it would have been nice to separate AddToFunc into 2 separate commands - AddToMouseFunc AddToFunc. Where AddToMouseFunc would permit modifiers, AddToFunc would _always_ assume an Immediate modifier. 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. Is it not possible to determine whether a function must grab as it is defined? Couldn't adding a line with a modifier that needs a grab set a this function might need a grab flag?
Re: ModuleListenOnly command
On Sun, Jun 25, 2006 at 02:09:49PM -0500, Jacob Bachmeyer wrote: Is it not possible to determine whether a function must grab as it is defined? Couldn't adding a line with a modifier that needs a grab set a this function might need a grab flag? You want to read this thread (it's long): http://www.mail-archive.com/fvwm@lists.math.uh.edu/msg10052.html -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: ModuleListenOnly command
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. But I suppose that should be a 2.6 feature? 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? Re: grabbing and complex functions. I'll reply to this in a new thread with a more appropriate subject. SCoTT. :)
Re: ModuleListenOnly command
On 24 Jun 2006 13:58:30 +0200, Dominik Vogt wrote: I have just checked in the new command ModuleListenOnly. It works like Module, but fvwm does not send any messages to such a module. I am using it to attach a shell script to the module interface that periodically updates titles of FvwmButtons to display a clock (in the format I prefer, xclock is too stupid) and the process that currently consumes most cpu. I can't say I am very happy about this. Actually, I would not be happy about any new feature added without discussion before 2.6.0. :) The problem with this solution is that in order to use it, every script should include non obvious parts of the module interface, and once the interface is changed such scripts stop to work correctly. AddToFunc InitFunction + I ModuleListenOnly /home/users/bin/fvwm_periodic ... AddToFunc RestartFunction + I ModuleListenOnly /home/users/bin/fvwm_periodic ... I would use StartFunction here, once. But, if I understand correctly, the script does not quit when you quit or restart fvwm (because a pseudo module does not really communicate with fvwm), so you also need to kill it in ExitFunction. I may see several solutions using the existing commands and not having such problems. FvwmCommandS and Exec is one solution that doesn't require the module protocol knowledge. There are several perl-based solutions. We may write a module FvwmButtonsUpdater that gets an FvwmButtons module name (alias) and a list of entries, each is: a button id, its update frequency and a shell command to invoke for title updates (for example, 'date +%T' or 'ps -A --format %C %P %c | sort -n -r | head -1'). Maybe someone will write such configurable module, useful for everybody. It is not very hard after reading fvwm-perllib man. Regards, Mikhael.
Re: ModuleListenOnly command
On Sat, Jun 24, 2006 at 02:08:43PM +, Mikhael Goikhman wrote: On 24 Jun 2006 13:58:30 +0200, Dominik Vogt wrote: I have just checked in the new command ModuleListenOnly. It works like Module, but fvwm does not send any messages to such a module. I am using it to attach a shell script to the module interface that periodically updates titles of FvwmButtons to display a clock (in the format I prefer, xclock is too stupid) and the process that currently consumes most cpu. I can't say I am very happy about this. Actually, I would not be happy about any new feature added without discussion before 2.6.0. :) Hm, I don't see that happen in the foreseeable future. Nobody is doing anything in that direction. The problem with this solution is that in order to use it, every script should include non obvious parts of the module interface, and once the interface is changed such scripts stop to work correctly. Oh, but it doesn't. All it relies on are the command line arguments and the message format. Both is documented. The only thing I did not care to find out in my script is the size and byte order of a long. (The SET_MASK stuff was left over from the pre-ModuleListenOnly version and can be removed). AddToFunc InitFunction + I ModuleListenOnly /home/users/bin/fvwm_periodic ... AddToFunc RestartFunction + I ModuleListenOnly /home/users/bin/fvwm_periodic ... I would use StartFunction here, once. But, if I understand correctly, the script does not quit when you quit or restart fvwm (because a pseudo module does not really communicate with fvwm), so you also need to kill it in ExitFunction. It exits when it gets a SIGPIPE, just like any other module. Of course you have to code it that way: trap 0 1 2 3 9 13 15 exit I may see several solutions using the existing commands and not having such problems. FvwmCommandS and Exec is one solution that doesn't require the module protocol knowledge. There are several perl-based solutions. Fact is, starting FvwmCommand every time I want to send a command disturbs the system because it needs to start a process. With the exception of the ps- and sort-commands, my fvwm_periodic module is a pure zsh-script, and that's because I could not figure how to do it without calling an external command. And eventually I wasn't able to find out how to do it with FvwmPerl by reading the man page (I'm a zsh-person, not a Perl-person). We may write a module FvwmButtonsUpdater that gets an FvwmButtons module name (alias) and a list of entries, each is: a button id, its update frequency and a shell command to invoke for title updates (for example, 'date +%T' or 'ps -A --format %C %P %c | sort -n -r | head -1'). Maybe someone will write such configurable module, useful for everybody. That's the idea. My script should eventually end up with its portability issues fixed (although I don't see how all this could be done without zsh). It is not very hard after reading fvwm-perllib man. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: ModuleListenOnly command
Hi Dominik Mikhael, We may write a module FvwmButtonsUpdater that gets an FvwmButtons module name (alias) and a list of entries, each is: a button id, its update frequency and a shell command to invoke for title updates (for example, 'date +%T' or 'ps -A --format %C %P %c | sort -n -r | head -1'). Maybe someone will write such configurable module, useful for everybody. It is not very hard after reading fvwm-perllib man. Why use a module for something so simple? AddToFunc MyPeriodicFunc + I PipeRead 'echo SendToModule FvwmButtons ChangeButton clock Title $(date +%R %a %d.%m.)' + I PipeRead 'str=$(/bin/ps -A --format %C %P %c | sort -n -r | tail -n1) ; echo SendToModule FvwmButtons ChangeButton topproc Title $str' + I Schedule 15000 MyPeriodicFunc Schedule 3000 MyPeriodicFunc The topproc calculation can be tidied up. This is just a proof-of-concept. SCoTT. :)
Re: ModuleListenOnly command
+ I PipeRead 'str=$(/bin/ps -A --format %C %P %c | sort -n -r | tail -n1) Sorry, that should be 'head', of course. (or drop the '-r' flag on 'sort'.) SCoTT. :)
Re: ModuleListenOnly command
On Sun, Jun 25, 2006 at 03:22:57AM +1000, Scott Smedley wrote: We may write a module FvwmButtonsUpdater that gets an FvwmButtons module name (alias) and a list of entries, each is: a button id, its update frequency and a shell command to invoke for title updates (for example, 'date +%T' or 'ps -A --format %C %P %c | sort -n -r | head -1'). Maybe someone will write such configurable module, useful for everybody. It is not very hard after reading fvwm-perllib man. Why use a module for something so simple? AddToFunc MyPeriodicFunc + I PipeRead 'echo SendToModule FvwmButtons ChangeButton clock Title $(date +%R %a %d.%m.)' + I PipeRead 'str=$(/bin/ps -A --format %C %P %c | sort -n -r | tail -n1) ; echo SendToModule FvwmButtons ChangeButton topproc Title $str' + I Schedule 15000 MyPeriodicFunc Schedule 3000 MyPeriodicFunc The topproc calculation can be tidied up. This is just a proof-of-concept. Two reasons: (1) Schedule is an unreliable hack and (2) this starts a shell every 15 seconds and my goal was to waste as little cpu as possible (as it interferes with certain time-critical applications - okay - games). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: ModuleListenOnly command
On Sun, Jun 25, 2006 at 03:22:57AM +1000, Scott Smedley wrote: Why use a module for something so simple? AddToFunc MyPeriodicFunc + I PipeRead 'echo SendToModule FvwmButtons ChangeButton clock Title $(date +%R %a %d.%m.)' + I PipeRead 'str=$(/bin/ps -A --format %C %P %c | sort -n -r | tail -n1) ; echo SendToModule FvwmButtons ChangeButton topproc Title $str' + I Schedule 15000 MyPeriodicFunc Schedule 3000 MyPeriodicFunc It would be great if something like this worked (I would use this all the time ;), but sadly a module is the only option as the `Schedule` will never execute if the server is grabbed, rather than delaying until the grab has been released. (see execute_complex_function()) Tavis. -- - [EMAIL PROTECTED] | finger me for my pgp key. --- pgpxRmwVZvHVY.pgp Description: PGP signature
Re: ModuleListenOnly command
On 24 Jun 2006 16:35:21 +0200, Dominik Vogt wrote: On Sat, Jun 24, 2006 at 02:08:43PM +, Mikhael Goikhman wrote: I can't say I am very happy about this. Actually, I would not be happy about any new feature added without discussion before 2.6.0. :) Hm, I don't see that happen in the foreseeable future. Nobody is doing anything in that direction. But is this a reason to make this task harder? The problem with this solution is that in order to use it, every script should include non obvious parts of the module interface, and once the interface is changed such scripts stop to work correctly. Oh, but it doesn't. I don't see how what I said is not true. Unless there is fvwm-shelllib, every user script should include parts of the module interface (like function send), something that even modules in C and perl should not do. And eventually I wasn't able to find out how to do it with FvwmPerl by reading the man page (I'm a zsh-person, not a Perl-person). FvwmPerl is just a specific module for embedding perl into fvwm config, it does not have an easy-to-use support for periodic commands. Of course, options like --periodic-frequency and --periodic-cmd may be easily added. Still, specialized module FvwmButtonsUpdater would be more appropriate. We may write a module FvwmButtonsUpdater that gets an FvwmButtons module name (alias) and a list of entries, each is: a button id, its update frequency and a shell command to invoke for title updates (for example, 'date +%T' or 'ps -A --format %C %P %c | sort -n -r | head -1'). Maybe someone will write such configurable module, useful for everybody. That's the idea. My script should eventually end up with its portability issues fixed (although I don't see how all this could be done without zsh). It is not very hard after reading fvwm-perllib man. fvwm-themes includes FvwmThemesPanelManager module that periodically updates several button titles. It uses Schedule and Deschedule commands. There is also Scheduler tracker that hides all the dealing with these fvwm commands and provides a nice API: fvwm-perllib man FVWM::Tracker::Scheduler If Schedule command is not reliable (I didn't experience this myself), then this tracker may work using internal alarm method as well (someone may possibly improve this method). Regards, Mikhael.
Re: ModuleListenOnly command
On 6/24/06, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 24 Jun 2006 16:35:21 +0200, Dominik Vogt wrote: On Sat, Jun 24, 2006 at 02:08:43PM +, Mikhael Goikhman wrote: I can't say I am very happy about this. Actually, I would not be happy about any new feature added without discussion before 2.6.0. :) Hm, I don't see that happen in the foreseeable future. Nobody is doing anything in that direction. But is this a reason to make this task harder? Can we release a 2.6.0-rc1 and move on? Then while some would maintain it until a real 2.6.0, some would be working on 2.7. For the volunteers it's a matter of deciding to either help on perfecting 2.6.0 or on improving 2.7.0. The way things are, the project either dies or someone forks it. It's not going forward if we don't allow it to. Can we do it? Cheers, Renato
Re: ModuleListenOnly command
On Sat, Jun 24, 2006 at 10:09:03PM +0100, seventh guardian wrote: Can we release a 2.6.0-rc1 and move on? Then while some would maintain it until a real 2.6.0, some would be working on 2.7. For the volunteers it's a matter of deciding to either help on perfecting 2.6.0 or on improving 2.7.0. I wouldn't advise this, since all that is doing is playing version numbers games without there being any forethought or intent behind that move, other than to fit some psychological need that 2.6.0 *has* to be released soon. Many things have yet to be done -- that's evident all over the place, based what is in the TODO file, and what has already resulted from previous discussions on this list. What would probably have to happen before 2.6.0 is even thought about is a brain-storming idea, and prioritising those features currently out standing, or in the current 2.5.X tree that need fixing/improving. And be warned: it's going to take *a lot* of work. I had always hoped that when 2.6.0 hit, that would more or less mark the starting point for what the (very distant) FVWM3 might become. So the question is this: before all the numbers change in terms of versioning, and the happy-go-lucky followers of higher numbers means better software jump on their bandwagon, what needs doing? The way things are, the project either dies or someone forks it. It's not going forward if we don't allow it to. Welcome to the wonderful world of $REAL_LIFE. Things, alas, get in the way. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: ModuleListenOnly command
On 6/24/06, Thomas Adam [EMAIL PROTECTED] wrote: On Sat, Jun 24, 2006 at 10:09:03PM +0100, seventh guardian wrote: Can we release a 2.6.0-rc1 and move on? Then while some would maintain it until a real 2.6.0, some would be working on 2.7. For the volunteers it's a matter of deciding to either help on perfecting 2.6.0 or on improving 2.7.0. I wouldn't advise this, since all that is doing is playing version numbers games without there being any forethought or intent behind that move, other than to fit some psychological need that 2.6.0 *has* to be released soon. Well, if new features aren't welcome until 2.6.0 comes out, then there is a purpose of releasing 2.6.0. Many things have yet to be done -- that's evident all over the place, based what is in the TODO file, and what has already resulted from previous discussions on this list. What would probably have to happen before 2.6.0 is even thought about is a brain-storming idea, and prioritising those features currently out standing, or in the current 2.5.X tree that need fixing/improving. And be warned: it's going to take *a lot* of work. I had always hoped that when 2.6.0 hit, that would more or less mark the starting point for what the (very distant) FVWM3 might become. So the question is this: before all the numbers change in terms of versioning, and the happy-go-lucky followers of higher numbers means better software jump on their bandwagon, what needs doing? The problem, if it can be called so, is that fvwm uses the numbering scheme od - unstable, even - stable. Current version, 2.5.0 is almost stable, which prevents any major change, so there's really no unstable version now. Everything is frozen until 2.6.0 comes out, which (as so many times stated) may never hapen.. The way things are, the project either dies or someone forks it. It's not going forward if we don't allow it to. Welcome to the wonderful world of $REAL_LIFE. Things, alas, get in the way. Volunteers help when they can and WHERE they want. It's allways that way.. If the volunteers want to improve fvwm in a way that may break the current almost stable version, then I guess they should be allowed to. If that means playing with numbers, then why not? Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
