Re: FVWM: FVWM Wiki
On 04/16/2014 01:40 PM, Thomas Funk wrote: Hi there! I am wondering what's happening with the FVWM wiki on http://fvwmwiki.xteddy.org/ ? I remember there was a discussion to move it into FVWM's website or something like that. But now the wiki is gone and never appears anywhere :-/ Does anybody knows about that? Because it would be a pitty if these very well information are lost. The information is not lost, I have a copy of it and need to add it to the fvwmforums.org domain but the server didn't have new enough perl for the ikiwiki and I wasn't able to get a clean html dump of it. I tried at http://zensites.net/wiki/fvwmwiki-html/ as a test, but it didn't render the html correctly all the way Then I got distracted from learning ikiwiki jaimos
Re: FVWM: Forums and Wiki need new maintainers/homes
On 09/06/2013 12:06 PM, Bert Geens wrote: Thomas Adam writes: Hi Dan, On Thu, Sep 05, 2013 at 09:58:36PM -0400, Dan Espen wrote: Thomas Adam writes: Hi all, Given my diminishing work on FVWM, I need to think about handing over the FVWM Forums [1] and the FVWM Wiki [2]. I cannot devote the time needed for their maintenance, nor do I want to act as a point of contact for them anymore. From my point of view, I'd have no problem with closing them down. If you could direct users to the mailing lists, that would be a good thing. That'd be the simplest solution, yes. But I'm unclear how many users of FVWM and the forums would welcome that. I was always in favour of closing it down, but it exists _because_ it's what people wanetd, and still do, from what I can tell. They're certainly a lot busier than fvwm@ in terms of questions. The barrier to sending questions to mailinglists certainly is a lot higher for most people than posting to a forum (whether this is is an imaginary barrier or not is, in the end, irrelevant), which is the main reason I set up the Fvwm forums back then. If need be I will take over maintaining the forums again. The software is relatively low maintenance (certainly compared to the horror that was phpBB2). It would be nice if there would be some more knowledgeable moderators, my personal use of Fvwm is, to say the least, pretty basic. While I don't foresee a repeat of the issue that forced Thomas to take over maintaining the forum software it would certainly be nice if hosting could remain somewhere where more people have access to it in case of emergency. In other words, if Jaimos doesn't mind it would be nice if the forums could stay where they currently are. The wiki is less important, but there's a lot of documentation which I feel should make it in to the man pages somewhere if someone is wanting to do that. It would be a shame to lose the information stored in the wiki, I find it often more to the point that having to distill that same information form the manpage (assuming it's in there at all). For the time being I see no reason I cannot keep hosting the forums and host the wiki as well. This could change in the future (but I don't foresee such an event) and I would prefer to host if someone I have known via #fvwm or in the fvwm community for a while took charge of what little maintenance there is on the admin side. As for getting some more moderators for the forums themselves that could be useful and moderators do not need any access to the servers. I could help Bert with anything on the admin side of the server and keeping phpBB3 up and secure, but I too only use the very basic features of fvwm and don't want to be a moderator on the forums. One thing that could be useful on my end to save a small issue we had when I changed servers was having control of the domain names. I consider them part of the fvwm community but if I end up keep hosting the forums and the wiki it just saves time and hassle if I can access and control them directly instead of waiting for the owner of them to update DNS records and the likes. jaimos
Re: FVWM: how to? FakeClick for Middle button
On 01/25/2013 08:23 AM, Spoofing wrote: sup. I like to use "Shift + Insert" for paste text from clipboard everywhere, and for example, when I run Firefox, want to press "Shift + Insert" for open URL from clipboard, like the mouse middle (button 2) click. Key Insert A S FakeClick depth 2 press 2 wait 250 release 2 doesn't work, and also try to change depth, but nothing happens... how to simulate mouse middle click button with Shift + Insert? :) First, not all applications like fake (or synthetic) events, and as per the man page FakeClick and FakeKeyPress are for debugging fvwm and not going to work in all situations. So your approach should be rethought. Second it is not firefox that 'pastes' when you click the middle mouse button. It is xorg that intercepts the middle mouse click and then sends the resulting paste to the window. So sending the middle mouse button click to the root window or the firefox window (or any other window) will note generate the paste event. Firefox does not know to paste when it receives a middle mouse click. On the other hand firefox and many applications honor the ctrl-V paste button. In my testing I got FakeKeyPress depth 2 modifiers 8 press v To work just fine and correctly paste something into chromium (provided I copied with ctrl-C from an application first). So that may work for you, but now you need to get a clipboard manager to keep the clipboard and cutbuffer in sync. It looks like something like 'autocutsel' may do that for you. Though it could be possible that there are more advanced clibboard managers and you could use one of those to not only keep the two methods of copying/pasting in sync can probably set up custom key bindings to send the clibboard to the desired window. This is the direction I would look. It looks like clipit may have that functionality. Using FakeKeyPress to make shift-insert work like ctrl-V will only work for applications which already honor ctrl-V so you are just changing the default. It will have no effect (or even other effects) because each application will honor the ctrl-V how ever it deems is correct. So even though that works in some applications it may not do what you want. So I think getting a clipboard manager that has the feature to set up a keybinding would be the direction to go (note I have never messed with them, so I am unsure what sort of things the clipboard managers can do). jaimos
Re: FVWM: Debian Unstable now has FVWM 2.6.5
On 01/23/2013 11:29 AM, E Frank Ball III wrote: On Wed, Jan 23, 2013 at 01:53:32PM +, Thomas Adam wrote: > Hi, > > Just a quick note to all the Debian users who've long since been waiting for > Debian to update their version of FVWM, this has finally happened. > > I've been helping out the new maintainer and talking to the DD who's > sponsering the maintainer, and we've finally got FVWM 2.6.5 released to > Debian Unstable. > > Someone may well backport this; I don't know. Thank you, thats great. Any chance it will make it into Wheezy? Wheezy is frozen so most likely not. jaimos
Re: FVWM: Smart maximize
On 11/28/2012 10:17 AM, Bastian wrote: Have you tried to set the Style MinPlaceOverlap to subjected window and then call PlaceAgain on it? This works for me: DestroyFunc movetofreeplace AddToFunc movetofreeplace + I WindowStyle MinOverlapPlacement + I PlaceAgain First please do not top post (read the rules of the mailing list). The problem with this method is that it will find the first available free (or min overlap) region it can place the window. If there are multiple rectangles on the screen that are free of windows it will always pick the first one it finds (not the biggest rectangle). So though it was a suggestion to look at there is really no nice way I can see to mix it to be able to grow a window to fit in the biggest possible rectangle it can find. A FvwmPerl script will end up being the the best way I can think of to first find the biggest free rectangle and then to move/resize the window to fit in that rectangle. The hard part will be the problem of finding the biggest open rectangle (this is a logic/math problem). Once you have that it is fairly straight forward to move the window to that rectangle and maximize grow grow (or just resize it) to the right size. jaimos
Re: FVWM: set style by state
On 11/07/2012 02:07 AM, Bastian wrote: DestroyFunc F1 AddToFunc F1 + I All (FvwmConsole) + I Move w+10 w+0 + I Move w+0 w+10 Most likely you only have a single window named FvwmConsole, so this All command only gets a single window and the once it has the context of that single window it knows which one to move. Try running this function if you have two FvwmConsole windows open. See what happens. DestroyFunc PullTaggedWindows AddToFunc PullTaggedWindows + I All (State $0) + I Move w+10 w+0 + I Move w+0 w+10 What happens here is you are most likely matching multiple windows. You aren't telling fvwm to move each window but only to move one window (in which you used the conditional to get the correct window context). Since fvwm cannot determine which one window you wanted to move to is asking you which one to move. Hence + I All (State $0) CustomMoveFunction where the CustomMoveFunction does your move. That command will run that function on each and every window it matches (instead of just trying to get the window context for the rest of the function). jaimos
Re: FVWM: set style by state
On 11/05/2012 09:04 AM, Bastian wrote: On 05Nov12 08:40 -0700, Jaimos F Skriletz wrote: So you could do something like this AddToFunc TagWindow + I Pick + I TestRc (Error) Break + I State $0 1 + I WindowStyle BorderColorSet foo, HilightBorderColorset bar If you have a way to toggle the state of the window (so you can turn off State 10 in your case, you will have to do something similar and reverse the colorset change on the border color) Thank you for this comprehensive instructions. Using WindowStyle does the job. Off topic: Using conditional commands (Pick, All ,...) without a command in the same line does not work for me. In general that is correct, you need All (conditions) Action, Next (conditions) Action, etc The idea is things like Raise, Move, WindowStyle need to know what window you want to do it for and the conditionals find the right window. ThisWindow is a useful one to use once you already have the window chosen/context is known. I am under the impression that Pick is slightly different in once you pick the window the context is known so you only have to pick the window once and then run multiple things on that window. That example I gave you comes directally from the man page for FVWM 2.6.5 so if it doesn't work (I haven't had time to test it) it is a bug with the man page. In that case you may want to do something like this instead AddToFunc ToggleWindow + I Pick (Conditions) CustomStateFunction AddToFunc CustomStateFunction + I State ... + I WindowStyle ... + I Move ... and so forth. The reason why you want to do that is you don't want the function to pause and have you pick the window for each action in your function. The other option is to use the ThisWindow conditional, so + I ThisWindow (conditions) Action. I will admit I'm a bit unsure as to the proper method, but that should be enough to play with to get it to work as expected. jaimos
Re: FVWM: set style by state
On 11/05/2012 07:57 AM, Bastian wrote: State is for conditional expressions. We need more information about what you are trying to do. More in detail: Mouse 2 W 4 Function TagWindow 10 Mouse 2 R 4 Function PullTaggedWindows 10 DestroyFunc TagWindow AddToFunc TagWindow + I Pick State $0 1 When you tag your window you can do other things to it. One useful tool is WindowStyle. It will change the Style of the window in question. So just like your TagWindow function picks a window to set to State 10, you can use that to set the WindowStyle to change the border color (or do other options) on that window. So you could do something like this AddToFunc TagWindow + I Pick + I TestRc (Error) Break + I State $0 1 + I WindowStyle BorderColorSet foo, HilightBorderColorset bar You can of course add other options/actions to that window you picked (note the second line is just to stop the function if a window wasn't sucessfuly picked). You might also prefer to use + I Pick (conditions) and put some sane conditions so you don't accidently pick a window you don't want to (like transient windows, pannels, etc) If you have a way to toggle the state of the window (so you can turn off State 10 in your case, you will have to do something similar and reverse the colorset change on the border color) jaimos
Re: FVWM: can not unlock "date time" tool
On 10/18/2012 09:47 AM, Roger Campbell wrote: Some where things went bad and I was unable to set the background and the "date& time" tool any more. I can bring the tool up but I can not unlock the tool. I still can not unlock the "date and time" tool. The error in ~/.xsession-errors is : (gnome-control-center:2202): Gtk-WARNING **: Error acquiring \ permission: Failed to acquire permission for action-id \ org.gnome.controlcenter.datetime.configure It appears that you are trying to use the gnome date/time tool. Not sure if you have some policykit or issue with that but are you running a gnome pannel in fvwm? Fvwm does not come with a date/time tool. So support for that tool is not what this mailing list is for. So the issue you are having is with the gnome tool you are trying to use. My suggestion would be to use a far simpler tool such as FvwmScript (which getts the output of date from the cli), xclock, or many other simple clocks. You can then choose run this clock as its own window and position it somewhere or swallow it into a pannel such as FvwmButtons. If you want realtime up to the second xclock would be the best choice. I use fvwm script myself but my clock can be up to 15seconds off the real time as I don't refresh it every second. If you want to configure xclock's background read the manpage for the options/resources to set the colors. If you decided to use FvwmScript, you should have been shiped with a sample script for the date-time and you just need to configure a Colorset for it. jaimos
Re: FVWM: $PATH in Test x
On 05/01/2012 12:53 PM, Dominique Michel wrote: A very common way to write $HOME in a path is with ~ With "PATH="~/bin:$PATH" into ~/.bash_profile, I get only the first menu line on the screen. With "PATH="/home/dom/bin:$PATH" into ~/.bash_profile, I get the 2 menu lines on the screen. It look like the "Test (x xdradio) ..." work only in the first case. Is it a bug in fvwm or somewhere else, or some obscure and wanted stuff I am not aware of? It is an issue with the shell, and how it expands special characters. When the shell encounters an Env Variable or a special character like ~, *, !, etc it exapnds it based on the rules of the character. So when you have PATH="~/bin/:$PATH" because of the way the shell works it will expand $PATH correctly but it will not mess with the character "~" because it is inside quotes. What you should do it type this in a shell echo $PATH and you will see that your PATH still contains the ~ and it wasn't expanded to your home directally like it should have been. What this does is confuse things that use the PATH variable. Some may expand the ~ but my guess is most won't. It is preferable to do PATH="$HOME/bin:$PATH" to ensure everything gets expanded correctly by the shell. Another issue is putting a * or a ? in there would also cause issues because the shell is instructed to not expand things because of being between quotes. jaimos
Re: FVWM: limiting window movement to working area
On 04/12/2012 09:23 AM, Thomas Adam wrote: I toyed with the idea of having wall-boundaries where windows couldn't be moved, but due to the way one can configure their DesktopSize, and flip between pages when resizing/moving windows, etc., soon came to the realisation it becomes impossible to give a realistic configuration. Therefore, you won't ever get hard-walled areas honouring the EWMH Working Area for interactive window moves. As for your current problem, just use Layers, perhaps? -- Thomas Adam Would it be possible and useful to set an invisiable boundary that could be used with SnapAttraction or EdgeMoveDelay/EdgeMoveResitance over the EWMH boundaries. This way things can still be moved anywhere but there is a bit of resistance or snaping to the borders (even if there isn't a pannel there to snap to)? I am thinking allowing the EWMH bounderies to behave more like the edge of the pages when moving things around, and something that is configurable to the amount of delay/resistance needed? jaimos
Re: FVWM: A small issue with SetEnv
On 03/12/2012 11:47 AM, Roman Grazhdan wrote:
It's about FvwmPiazza again. At cruncbanglinux forums Thomas kindly
proposed to use
ModulePath +:$./modules
There is an extra dollar sign in your ModulePath (I think that is
causing your issues):
Also you have using ./modules this is a relative path, but this could
cause issues depending on the cwd at the time that path is used, best to
use full paths.
From the fvwm man page
The ModulePath may contain environment variables such as
$HOME (or
${HOME}). Further, a '+' in the path is expanded to the
previous
value of the path, allowing easy appending or prepending
to the path.
For example:
ModulePath ${HOME}/lib/fvwm/modules:+
So I think you want ModulePath +:${HOME}/modules/ Though I think the
example in the manpage is better since it makes your custom path be
first on the module list over the default (This is useful if you want to
patch/use a custom fvwm module that already has the same name in the
full path).
Re: FVWM: confused about rounded borders
On 03/03/2012 12:06 AM, Globe Trotter wrote: Hi, Looking at a few themes, there seems to be talk of "patched fvwms" to get rounded borders on windows. Where does one get these "patched fvwms"? Archlinux seems to have the patches floating still and that is the place I would look. Seems they have done a bit to ensure they still apply to 2.6.x. I would only take the rounded corners one, they have a bunch of them, some which may not be relevant any more. But this is of course unsupported, have fun. jaimos
Re: FVWM: Touch Screens
On 02/24/2012 10:43 AM, Chris Siebenmann wrote: | One important aspect of project life cycles is the ability | how projects keep in step with general technical development. | | It may be the case that five or ten years from now a lot of computers | will be equipped with touch screens. | | It could be a good idea to think about how FVWM would cope | with touch screens in the future. Decisions should be made: | Is FVWM supposed to support touch screens sometime or not? | If touch screen support is a good idea, how are the steps to | achieve that goal? My personal opinion is that we don't currently know what the right window manager interface is for decent-sized touchscreen displays (displays that are not going to be single application/window at a time). Thus I feel that doing anything for touchscreens in FVWM right now is highly premature; any work on touchscreen window managers is likely to be highly experimental for years to come. There was a great multi touch screen demo I saw a few years ago I can't seem to find but here is something similar, and I would love to be running fvwm on one of those. Though I do agree that for the standard consumer such things are a ways off, it still dosen't hurt to start thinking about such things now. Though I don't think it is a major project for GSOC at this time. Yes I would love to be running FVWM on something like this http://www.youtube.com/watch?v=JfFwgPuEdSk jaimos
Re: FVWM: GSoC 2012: Project ideas
On 02/24/2012 07:56 AM, msib...@crosswire.com wrote: Ok, I give. There is no better way than FVWM. Thanks! That was not the point, it is just another extreme stance. FVWM is good at what it does, dosen't mean it is the best, as this is usually personal opinion. A rewrite of FVWM would only waste the time of the developers that could be spent on projects that actually add functionality to improving FVWM. jaimos
Re: FVWM: GSoC 2012: Project ideas
On 02/17/2012 03:49 PM, Dan Espen wrote: Thomas Adam writes: On Fri, Feb 17, 2012 at 02:10:54PM -0700, Jaimos Skriletz wrote: 2) Rewrite the menu syntax and redsign the object, there was some talk about this on the mailing list years ago now and some good ideas for And the link to that thread is? http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg07167.html Hmm. This is terrible. If only because menus are treated here as some kind of alien-citizen and if this suggestion was to ever go through they should be treated the same way in FVWM like any other entity. Seems to be a lot of change with no new function. As I understand it, Fvwm can be accepting commands from many sources at the same time. Various modules can send commands to Fvwm, each is sent one at a time. I don't believe "+" is handled as it should be to account for this. This new design would make that worse. That was something I ran across years ago and saw it as thinking about a slightly more versatile syntax, though it is the functionality in the long run that is desired. I like how the idea was to give each menu item a more detailed list of properties, to allow for a larger variety in menu design. Such as being able to apply the different MenuStyles, Actions, etc to an individual item as opposed to the whole menu. And I think the current menu syntax is slightly limited in the ability to allow the above in a nice way. Though a slight modification of the current syntax to be more like FvwmButtons (item1, item2, item3) as another option. Something like AddToMenu MenuName (Item="xTerm",Hotkey="t",Action (Mouse 1) Exec xterm, Action (Mouse 3) Exec xterm -g 80x60,Colorset=,Icon=,Frame=,etc) The change of syntax was more along the thoughts of in order to improve functionality an improved config syntax could go hand in hand. It was just a suggestion, but after thomas mentioned that adding most (if not all) the functionality is on the TODO list and not a large project, there are plenty of other ideas to work with for GSoC. jaimos
Re: FVWM: Taking a break...
Thomas Adam wrote: Hi all, It umm, well it seems I can't quite deal with this how I'd like, so for the benefit of the project, I think I will take a short break -- I appreciate "sticks and stones" and all that, but when someone has repeatedly wished you would drop dead, it is a little dis-heartening. So I will take a break and possibly come back. -- Thomas Adam Best of luck to you Thomas. Over the years I have grown to appreciate and enjoy your insights and how much you have helped the FVWM community. I know you will find a place in which you will be truly appreciated for your generosity and ability. Here is wishing to see you again. jaimos
Re: FVWM: starting up applications
Darren Upsolla wrote: From: des...@verizon.net Date: Wed, 16 Sep 2009 20:33:29 -0400 Generally you should use InitFunction to start applications: DestroyFunc InitFunction AddToFunc InitFunction + I Exec exec xsetroot -solid cyan + I Exec exec xterm + I Exec exec firefox oh - but that post says: "*INITFUNCTION IS CALLED ONCE -- AT INIT TIME WHEN FVWM FIRST STARTS. STARTFUNCTION IS CALLED AT INIT AND RESTART.* So you can see now that you only need one function for your purposes, as you can add checks to StartFunction to tell it to do one thing if FVWM is initialising, and another if it's not (i.e., presumably at restart)." maybe thats why i am confused lol! why is this not in the manpage then? Yes InitFunction, StartFunction, RestartFunction were the older way of doing it. Now due to Test () this can all be done in a single function StartFunction. I think it makes things a bit easier to locate and keep track of. I am unsure if the InitFunction and RestartFunction will be depreciated in the future. The trend I see is to use only a StartFunction and Test (). This is in the man page: You do not need to define all special functions if some are empty. Also note, all these special functions may be emulated now using StartFunction and ExitFunction, like this: DestroyFunc StartFunction AddToFunc StartFunction + I Test (Init) Module FvwmBanner + I Module FvwmPager * * + I Test (Restart) Beep DestroyFunc ExitFunction AddToFunc ExitFunction + I Test (Quit) Echo Bye-bye + I KillModule MyBuggyModule + I Test (ToRestart) Beep jaimos
Re: FVWM: starting up applications
Darren Upsolla wrote: hi Date: Wed, 16 Sep 2009 17:38:21 -0300 Subject: Re: FVWM: starting up applications From: joqu...@gmail.com To: abovefrombe...@hotmail.com init sorry what does this mean? Darren The response was to use the 'initfunction' as your requested. Though it is better to put all startup commands into a single function. This function is called the StartFunction DestroyFunc StartFunction AddToFunc StartFunction + I + I + I Test (Init) + I Test (Restart) StartFunction is ran after fvwm starts up and reads though your config. It will run every time fvwm is started. Some things like FvwmModules will need to be started every time while others you may only want to run on the initial start up or on a restart. The Test () option says to only run that action under particular conditions. With this you can customize any number of fvwm to run at start up and separate them into various test conditions. i.e. Screensavers, wallpaper settings only need to be ran once, while FvwmModules will need to be run each time you restart. jaimos
Re: FVWM: thomas adam ill
Dominik Vogt wrote: On Sun, Sep 13, 2009 at 10:31:02AM -0400, des...@verizon.net wrote: Darren Upsolla writes: it has been brought to me attention thomas adam is seriously ill - just thought you should know darren Very sad news indeed. His contributions have been much appreciated. Yes, very sad. My best wishes to him, I hope he gets better. I talked to Thomas today, this is just a bad rumor. I'm just letting everyone know he said he is fine and to disregard this bad rumor before it goes any further.
Re: FVWM: fvwm crash when setting the mini-icon
Gautam Iyer wrote: On Tue, Aug 18, 2009 at 08:20:59PM -0600, Jaimos F Skriletz wrote: My work has OpenSuse 11.1 systems (64-bit), and I notice that Fvwm (2.6.26 and 2.6.27) crashes when I do the following Pick WindowStyle MiniIcon vim.png (basically set any icon which is not the window's current icon, and locatable by Fvwm in the image path). This leads to an immediate crash, with no error messages. The last couple of lines in my .xsession-errors are: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 7141 requests (7000 known processed) with 0 events remaining. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 102 requests (102 known processed) with 0 events remaining. The same happens when I run Fvwm under VNC, as opposed to Fvwm under X directly (so I'm guessing it's not server dependent). Once fvwm crashes because of this error, it reload it (via commandline) without restarting the VNC server causes fvwm to segfault. I should also add that on my Gentoo laptop, I don't see the above error. I checked to see if I had the issue and it does not crash my system at all. I'm running debian (sid) amd64 bit. I am not sure what the issue could be. My fvwm version is a cvs (2.5.28) from a month ago. fvwm --version fvwm 2.5.28 (from cvs) compiled on Jul 12 2009 at 20:59:11 with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS I'd suggest first trying the current cvs version and seeing if it works there. If you still are getting crashes in the current cvs version then provide some more info like compile options from fvwn --version to help debug where the issue is. Ok, I just checked with the CVS version. (I also noticed that the error message I get after resetting the MiniIcon is a friendly "Segmentation fault"). So I can confirm the crash on 2.5.26, 27 and 28CVS. Here's my version info: fvwm 2.5.28 (from cvs) compiled on Aug 18 2009 at 22:33:07 with support for: ReadLine, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS I myself am baffled by this, since on my Gentoo box, no matter what I do I can't crash it. Any suggestions? GI Is it only with .png files, try to use a xpm or a svg icon? I'd assume you'd still crash but only thing I can think of. I would also suggest to see if you can set the MiniIcon though a command like Style "appname" MiniIcon file.png Just thinking of things that could narrow down where the issue is. jaimos
Re: FVWM: fvwm crash when setting the mini-icon
Gautam Iyer wrote: Hi All, My work has OpenSuse 11.1 systems (64-bit), and I notice that Fvwm (2.6.26 and 2.6.27) crashes when I do the following Pick WindowStyle MiniIcon vim.png (basically set any icon which is not the window's current icon, and locatable by Fvwm in the image path). This leads to an immediate crash, with no error messages. The last couple of lines in my .xsession-errors are: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 7141 requests (7000 known processed) with 0 events remaining. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 102 requests (102 known processed) with 0 events remaining. The same happens when I run Fvwm under VNC, as opposed to Fvwm under X directly (so I'm guessing it's not server dependent). Once fvwm crashes because of this error, it reload it (via commandline) without restarting the VNC server causes fvwm to segfault. I should also add that on my Gentoo laptop, I don't see the above error. How do I fix this? Thanks, GI I checked to see if I had the issue and it does not crash my system at all. I'm running debian (sid) amd64 bit. I am not sure what the issue could be. My fvwm version is a cvs (2.5.28) from a month ago. fvwm --version fvwm 2.5.28 (from cvs) compiled on Jul 12 2009 at 20:59:11 with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS I'd suggest first trying the current cvs version and seeing if it works there. If you still are getting crashes in the current cvs version then provide some more info like compile options from fvwn --version to help debug where the issue is. jaimos
