fvwm cvs and gkrellm race condition
I may have found a bug, to reproduce... 1. I start fvwm without a rc file, 2. then execute gkrellm from a xterm, 3. then I click on the gkrellm window(not the fvwm decorations) and wiggle it around. 4. repeat step 3 a few times. fvwm, gkrellm and X start fighting for cpu use. Memory used starts filling up really fast. And I cant do anything execpt ctrl-alt-bkspce. GKrellM 1.2.13 gtk 1.2.10 Xfree86 4.2.0 Linux 2.4.19 i686 AuthenticAMD [EMAIL PROTECTED] ~ % fvwm-config -i Package: fvwm Version: 2.5.3 Instalation options: prefix: /home/sa/local exec-prefix: /home/sa/local bindir: /home/sa/local/bin datadir: /home/sa/local/share libexecdir: /home/sa/local/libexec sysconfdir: /home/sa/local/etc mandir: /home/sa/local/man Compiled-in paths: Module directory: /home/sa/local/libexec/fvwm/2.5.3 Data directory: /home/sa/local/share/fvwm Perl lib directory: /home/sa/local/share/fvwm/perllib Default ImagePath: /usr/include/X11/bitmaps:/usr/include/X11/pixmaps Default UserDir: $HOME/.fvwm Support for features: bidi (bi-directionality): no ewmh (Extended Window Manager Hints): yes gnome-hints (window manager hints): yes gtk (required for FvwmGtk): yes gdk-imlib (in FvwmGtk): yes gnome-libs (in FvwmGtk): yes perllib (Perl library installed): yes png: yes readline: yes rplay: no shape (shaped windows): yes sm (session management): yes stroke (mouse gestures): yes xinerama (multi-head): yes xft (FreeType anti-alias font): yes xpm: yes xrender (XFree86 Xrender extention): yes let me know if you need any other info, cya, sa -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS olicha: * Implemented dithering for depth 16 and 15:
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 02/08/13 01:08:45 Modified files: . : ChangeLog NEWS fvwm : builtins.c fvwm.1 libs : PictureUtils.c Log message: * Implemented dithering for depth 16 and 15: This is off by default in colorset (use the dither colorset option) and on by default for window title gradient. Gradient are visibly more smooth. * Color limit and dithering news * Some cleanup * Added a minimal doc for the -color-limit option (more doc at the end of august) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: fvwm cvs and gkrellm race condition
On Mon, Aug 12, 2002 at 10:07:14PM -0600, S. Anderson wrote: I may have found a bug, to reproduce... 1. I start fvwm without a rc file, 2. then execute gkrellm from a xterm, 3. then I click on the gkrellm window(not the fvwm decorations) and wiggle it around. 4. repeat step 3 a few times. fvwm, gkrellm and X start fighting for cpu use. Memory used starts filling up really fast. And I cant do anything execpt ctrl-alt-bkspce. GKrellM 1.2.13 gtk 1.2.10 Xfree86 4.2.0 Linux 2.4.19 i686 AuthenticAMD [EMAIL PROTECTED] ~ % fvwm-config -i Package: fvwm Version: 2.5.3 With the same versions, it doesn't happen here. Is the fvwm-2.5.3 latest CVS? let me know if you need any other info, Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Fixed taskbar/autostick races.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/08/13 06:26:27 Modified files: modules: ChangeLog modules/FvwmTaskBar: FvwmTaskBar.c FvwmTaskBar.h Log message: * Fixed taskbar/autostick races. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Fixed taskbar/autostick races.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/08/13 06:26:41 Modified files: . : Tag: branch-2_4 NEWS modules: Tag: branch-2_4 ChangeLog modules/FvwmTaskBar: Tag: branch-2_4 FvwmTaskBar.c FvwmTaskBar.h Log message: * Fixed taskbar/autostick races. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Fix for FVWM_...DIR with spaces in path names.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/08/13 07:57:06 Modified files: . : ChangeLog configure.in Log message: * Fix for FVWM_...DIR with spaces in path names. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: fvwm cvs and gkrellm race condition
On Tue, Aug 13, 2002 at 11:40:28AM +0200, Dominik Vogt wrote: On Mon, Aug 12, 2002 at 10:07:14PM -0600, S. Anderson wrote: I may have found a bug, to reproduce... 1. I start fvwm without a rc file, 2. then execute gkrellm from a xterm, 3. then I click on the gkrellm window(not the fvwm decorations) and wiggle it around. 4. repeat step 3 a few times. fvwm, gkrellm and X start fighting for cpu use. Memory used starts filling up really fast. And I cant do anything execpt ctrl-alt-bkspce. GKrellM 1.2.13 gtk 1.2.10 Xfree86 4.2.0 Linux 2.4.19 i686 AuthenticAMD [EMAIL PROTECTED] ~ % fvwm-config -i Package: fvwm Version: 2.5.3 With the same versions, it doesn't happen here. Is the fvwm-2.5.3 latest CVS? yes updated on aug 12th. I downloaded fvwm-snap-20020810 and It doesnt have this problem. I just figured out, If I #undef EXPERIMENTAL_ANTI_RACE_CONDITION_CODE in fvwm/events.c at line 1081 I dont have this problem anymore. is the experimental anti race condition code important, should I not disable it? also I forg÷t to mention I am using gcc 3.1.1, and It is not only gkrellm, but xmms and xine too. cya, sa -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: QuitFunction
Hi, I am using xplanet to update my background every couple of minutes. When i quit fvwm, i would like to kill xplanet so that it doesn't keep on running. A QuitFunction (called only when actually quitting) would be convenient for this, but i can't seem to find it in the manual. Why is this ? thanks, Remko -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: QuitFunction
On 13 Aug 2002 08:29:48 +0200, Remko Troncon wrote: I am using xplanet to update my background every couple of minutes. When i quit fvwm, i would like to kill xplanet so that it doesn't keep on running. A QuitFunction (called only when actually quitting) would be convenient for this, but i can't seem to find it in the manual. Why is this ? It's named ExitFunction. Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: QuitFunction
It's named ExitFunction. Yes, i saw the ExitFunction. But the man page says that this function is called on restarts also. I only want to kill xplanet when actually quitting. cheers, Remko -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: QuitFunction
On 13 Aug 2002 09:00:30 +0200, Remko Troncon wrote: It's named ExitFunction. Yes, i saw the ExitFunction. But the man page says that this function is called on restarts also. I only want to kill xplanet when actually quitting. Well, you may start xplanet in StartFunction instead of InitFunction and ExitFunction will work for you like you want. Or run an fvwm wrapper like this: xplanet fvwm killall xplanet # or: kill `pidof xplanet` Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: QuitFunction
Well, you may start xplanet in StartFunction instead of InitFunction and ExitFunction will work for you like you want. That's not really what you would want to do with xplanet. Or run an fvwm wrapper like this: xplanet fvwm killall xplanet # or: kill `pidof xplanet` This is indeed a solution, but i was wondering if it could be moved inside fvwm. Is there a reason why there is no such QuitFunction ? cheers, Remko -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: QuitFunction
On 13 Aug 2002 09:30:11 +0200, Remko Troncon wrote: Well, you may start xplanet in StartFunction instead of InitFunction and ExitFunction will work for you like you want. That's not really what you would want to do with xplanet. I don't see a problem with this. Or run an fvwm wrapper like this: xplanet fvwm killall xplanet # or: kill `pidof xplanet` This is indeed a solution, but i was wondering if it could be moved inside fvwm. Is there a reason why there is no such QuitFunction ? Noone just needed it, because other solutions exist. We would also need PreRestartFunction for completeness. And SessionQuitFunction with SessionPreRestartFunction. When I added StartFunction (to avoid a module startup duplication) there were some voices saying too many special functions is not very good. But if there are more people that can't live without QuitFunction it may be trivially added. Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: QuitFunction
I don't see a problem with this. It's a pure luxury problem. When fvwm is restarted, xplanet doesn't have to be restarted because all it does is update the background. Restarting it on every fvwm restart is CPU intensive, and causes the background to blank out for a few seconds. Noone just needed it, because other solutions exist. We would also need PreRestartFunction for completeness. I'm not saying that i _really_ need it, because as you said before, it can be moved out of fvwm inside a wrapper. But now that i read the manual more thoroughly, i get your point on needing Pre-restart functions. I had the impression that the functions were organized this way (which they aren't): - InitFunction: called upon initialization only - QuitFunction (doesn't exist): called when the user quits only - StartFunction: called after InitFunction (when initing) or after RestartFunction (when restarting) - RestartFunction: called before QuitFunction (when quitting) or before StartFunction (when restarting) My intuition behind this was that, things you want to do before a restart (RestartFunction) and after a restart (StartFunction) , you also want to do before quitting and after initing respectively. I hope this makes any sense to you at all ;) cheers, Remko -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: QuitFunction
Why don't you just start it in the ~/.xinitrc file? That's what i was planning to do. But for some strange reason, i preferred to have it in my fvwmrc, and have as less as possible inside my .xinitrc. (i know, it's a purely subjective principle, but that's just my feeling :) Anyway, i'll stick with the .xinitrc file. cheers, Remko -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: QuitFunction
On 13 Aug 2002 13:41:15 +0200, Remko Troncon wrote: Why don't you just start it in the ~/.xinitrc file? That's what i was planning to do. But for some strange reason, i preferred to have it in my fvwmrc, and have as less as possible inside my .xinitrc. (i know, it's a purely subjective principle, but that's just my feeling :) My feeling too, .xinitrc is mostly for X settings. Apllications like background painters are usually a part of a theme, may be different on different X starts. Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: QuitFunction
On 13 Aug 2002 13:12:01 +0200, Remko Troncon wrote: I'm not saying that i _really_ need it, because as you said before, it can be moved out of fvwm inside a wrapper. But now that i read the manual more thoroughly, i get your point on needing Pre-restart functions. I had the impression that the functions were organized this way (which they aren't): - InitFunction: called upon initialization only - QuitFunction (doesn't exist): called when the user quits only - StartFunction: called after InitFunction (when initing) or after RestartFunction (when restarting) I know 2 reasons for StartFunction to be first and one reason for it to be second. - RestartFunction: called before QuitFunction (when quitting) or before StartFunction (when restarting) But then RestartFunction would be run twice. My intuition behind this was that, things you want to do before a restart (RestartFunction) and after a restart (StartFunction) , you also want to do before quitting and after initing respectively. I hope this makes any sense to you at all ;) Now when I think about this, I see an elegant solution for these problems. We only need 2 functions (not including Session*Function variants), StartFunction and ExitFunction. StartFunction may include conditions StartUp and Restart, ExitFunction may include conditions Restart and Quit, these conditions are always false anywhere else. This way InitFunction and RestartFunction are not needed (not that RestartFunction is needed now anyway). AddToFunc StartFunction + I ModuleSynchronous FvwmPerl + I On (StartUp) FvwmBanner + I On (Restart) Exec play /some/dong.au + I FvwmButtons + I Exec xterm ... + I Wait + I Exec mozilla + I On (StartUp) Exec xplanet-runner + I FvwmPager AddToFunc ExitFunction + I On (Quit) Exec killall xplanet-runner + I On (Restart) Exec play /some/ding.au + I Echo Either Restart or Quit I don't know whether it is more intuitive or not. Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: QuitFunction
StartFunction may include conditions StartUp and Restart, ExitFunction may include conditions Restart and Quit, these conditions are always false anywhere else. This way InitFunction and RestartFunction are not needed (not that RestartFunction is needed now anyway). ... Your approach is indeed cleaner and more general than what i had in mind. Another advantage about this is that it's backward compatible. I don't know whether it is more intuitive or not. It is to me ! cheers, Remko -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: PipeRead and shell args
Running 2.4.7 on Solaris.
I have a function that accepts three arguments, the last of which is
optional; if omitted, I supply a default. Here's what's working:
AddToFunc MyFunc
+ I PipeRead 'BD=$2; BD=${BD:-4}; ... '
If I try to shorten it to this:
+ I PipeRead 'BD=${2:-4}; ... '
then BD is always 4 ($2 is seemingly ignored). sh is apparently
satisfied (no bad substitution error). Expected? Wrong syntax?
Gregg Dameron
--
Visit the official FVWM web page at URL: http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm in the body of a
message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: PipeRead and shell args
On 13 Aug 2002 12:18:15 -0600, Gregg Dameron wrote:
I have a function that accepts three arguments, the last of which is
optional; if omitted, I supply a default. Here's what's working:
AddToFunc MyFunc
+ I PipeRead 'BD=$2; BD=${BD:-4}; ... '
If I try to shorten it to this:
+ I PipeRead 'BD=${2:-4}; ... '
then BD is always 4 ($2 is seemingly ignored). sh is apparently
satisfied (no bad substitution error). Expected? Wrong syntax?
You can't shorten it. If you want the second function parameter to be
expanded by FVWM, you should write it as $2. Other shell-like syntaxes
like ${2} or ${2:-4} do not work, both these strings are passed to the
shell unexpanded if used inside PipeRead.
Regards,
Mikhael.
--
Visit the official FVWM web page at URL: http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm in the body of a
message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Documentation (was: Re: FVWM: How do I start modules automatically?)
Dominik Vogt wrote: On Fri, Aug 09, 2002 at 12:40:43PM -0400, Stephen Dennison wrote: What would you like to see in such a tutorial? That's a part of the job to figure that out. 2 cents' worth from a new arrival who badly needs such a tutorial. The postings (that I have read) look at suitable formats. But the real issue is _content|sequence of presentation_. My recent efforts to learn to use vim may serve as an illustration. My version of Linux installed vim-5.7. That did all that I am ever likely to need in an editor. But the documentation was unhelpful. I opted to update to vim-6.0 because it came with an Online Manual. The Manual has two parts: a Users Manual; and a Reference Manual. and it is utterly superb. An enormous amount of thought and effort must have gone into the preparation of the Users Manual in selecting the order in which topics are described and previously-described routines are shown in use at later stages - helping newcomers to refresh what they had learnt and had already forgotten again. This posting adds nothing that is not obvious to the experts - the requested project is of mammoth proportions. And if wishes were horses, beggars would ride. Felix Karpfen -- Felix Karpfen [EMAIL PROTECTED] Public Key 72FDF9DF (DH/DSA) -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: configure do not recognize xpm
Hi, all! Now FVWM2 are up and running nicely, with the win95 look I'd asked for. All what is left now is to edit setup to fit this installation, I'd start on that soon. What I've done is to (removed the extra xpm installation) (1) re-build xpm (NetBSD source package), as a result everything that depended on xpm were re-built as well, so it took the entire evening (do not ask how long, I'd went to bed). There have been a flaw in fvwm95 ( which is in current use ), when I'd click on a window, it comes to front, but do not receive focus. I'd have to click on the icon on button bar to gain focus. When X is recently started it works ok, when I'd click on a window, it gets to front and focus are gained, but after Netscape have crashed once or more, I dont get focus by clicking in a window any more. This behavior now seems to have disappeared, but I'd won't say its gone quite yet, this bug is of an periodic kind, it's important to be very patient. Furthermore I'd have tested the myfvwmtest program sent me from Mikhael Goikhman, and I'd found that some libXpm.so.4 library were missing. Links were made in /usr/lib, and after sucessful build, it reported XpmIncludeVersion=30411, XpmLibraryVersion=30411 as expected. Now, I'd (3) re-installed fvwm2: ./configure --with-xpm-library=/usr/X11R6/lib --with-xpm-includes=/usr/X11R6/lib .. this time config summary said XPM YES. Then I'd executed make and make install. It came up with that configure 95 in main menu, and soon I'd get that 95 look a like desktop. It seems like that xpm installation were bad. Some strange things also happened to fvwm2, this may or may not be related to all the xpm trouble, this time it found the setup 95 script, so the .fvwm2rc file were installed. Happy ending, despite it is'nt very clear how the scripts finally made it... Thank you very much all of you, and good luck with the fvwm development. Feel free to ask more questions. -- Regards, Sigmund Skjelnes -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Direct Draw?
David wrote: Hello, I hope someone else is also asking for direct draw fvwm. As it is now, when I start X11 in a cygwin shell, the xwindow comes up and the fvwm2 comes up. However, when I quit the cygwin shell, the window manager goes away and so do its child xterms. It used to be that the X11 root when away but now it survives. I hope an fvwm2 upgrade will enable the window manager to survive loss of the cygwin shell parent. David ps. Or, is there a workaround? it depends on how you start fvwm. some shells leave the kids running, some kill them (it might be configurable). if you want the program to run after you exit the shell regardles of which shell you are running use nohup (see man nohup). erik -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
