Re: FVWM: suddenly: a gnome-fvwm conflict problem
On Jul 26, 2007 at 12:16 am, Thomas Adam wrote: | | > So I guess ConfigFvwmDefaults works. I | > will try putting THAT file in ~/.fvwm (renaming it config) and see if | > that works. | | _NO_ -- just leave ConfigFvwmDefaults alone... please? I suspect what's | happening is that there's something in your ~/.fvwm/config doing something | weird -- such as StartFunction issuing some command, it's hard to say. | | I'd wish I'd never mentioned ConfigFvwmDefaults... | | -- Thomas Adam | OK, I had not realized that one's own config file's commands get ADDED to those in FvwmConfigDefaults (rather than replace that entire file). (Is that right?) So I will just try altering my config file and see if that works. (I will start with just a few commands that should be harmless.) But I was surprised that the sample fvwm2rc file also behaved in a way similar to my own config file, i.e., it did not work. Maybe I should try all three sample config files. Oh well. I will post anything I find that might possibly be useful. If something related to gnome just appeared on the scene (an update) that caused FVWM to misbehave it would be good to know about it. And actually I'm glad you DID mention ConfigFvwmDefaults, since knowing of its existence helps the understanding of how FVWM works. Thanks, -- Peter
Re: FVWM: suddenly: a gnome-fvwm conflict problem
On Wed, Jul 25, 2007 at 04:07:03PM -0700, Peter Scott wrote: > Yes I understand that ~/.fvwm is re-created when FVWM starts; however > since I had deleted mine (actually moved it to ~/.fvwm.save) there's no > config file in it. Nor is there any config file in any of the places > in the group you list 11 to 18 lines above. So it just reads the > "ConfigFvwmDefaults" file (which is actually, on my machine, > "/usr/share/fvwm/ConfigFvwmDefaults"). OK, so I will try adding lines Yes, that's right. (As I said.) And yes, often is the case that $(fvwm-config -d) will expand to either /usr/share/fvwm or /usr/local/share/fvwm. > (a few lines at a time) and see when things break. Does that sound like > a good strategy? (Thanks for telling me about "ConfigFvwmDefaults".) It does not sound like a good strategy, no. What is it you're really wanting (or _think_ you're achieving) by doing that? > Another possible strategy might be to pull some key lines from > "ConfigFvwmDefaults" (I see, for example, sections labeled > "# Needed by the ewmh support", and "# Needed by modules which use > session management") and insert them into my own config file. > Any idea what sections might be key? No, don't do that -- you get all of that for free anyway unless you explicitly and deliberately override it in your own ~/.fvwm2rc file. Forget I ever mentioned ConfigFvwmDefaults -- just leave it alone. > OK, what I did was to copy system.fvwm2rc from its location in the > source code directory to ~/.fvwm/ (renaming it "config"), then log on > in the usual way for gnome (gnome session with metacity as WM), then, > from a gnome-terminal, issue the command "fvwm -s 0 --replace". It is > at this point that things go awry, with fvwm seeming to start correctly > with a few flashing windows (with correct title bars) and an FvwmButtons > panel, then both the title bars and the FvwmButtons disappear and I am > left in the inoperable state I described earlier. Well that's certainly one way of doing it -- and that people have reported success with it before now. > (I also tried the slightly longer method, involving changing metacity to > "normal" in the sessions panel (+ apply) then issuing the command > killall metacity; sleep 2; fvwm &), but neither method works.) This isn't slightly longer, it's the more correct method. > What I'm saying is that the above process leads to problems whenever I > have either my own config or a sample config in ~/.fvwm, but that things > work correctly if there is no config file to be found in the above list > of places (and an error message appears on the screen with that list, > saying no config file found). So I guess ConfigFvwmDefaults works. I > will try putting THAT file in ~/.fvwm (renaming it config) and see if > that works. _NO_ -- just leave ConfigFvwmDefaults alone... please? I suspect what's happening is that there's something in your ~/.fvwm/config doing something weird -- such as StartFunction issuing some command, it's hard to say. I'd wish I'd never mentioned ConfigFvwmDefaults... -- Thomas Adam -- "He wants you back, he screams into the night air, like a fireman going through a window that has no fire." -- Mike Myers, "This Poem Sucks".
Re: FVWM: suddenly: a gnome-fvwm conflict problem
On Jul 25, 2007 at 8:05 pm, Thomas Adam wrote: | On Wed, Jul 25, 2007 at 11:52:02AM -0700, Peter Scott wrote: | > 1. If I delete $HOME/.fvwm (so my config file is gone) then fvwm starts | > under the gnome-session, although it complains about not being able to | > find a config (or .fvwm2rc) file. (What does fvwm use for a config in | > that case? I have no idea.) Of course then I get crummy titlebars | > (even over the gnome panels) etc., which I have no idea how to fix. | | OK, here's what FVWM does. (Why some of this isn't documented is beyond | me). When FVWM loads it loads a *minimal* internal set of commands -- just | the barebones so that *something* happens. Once that is done, it then goes | on to read: | | $(fvwm-config -d)/ConfigFvwmDefaults | | It's *this* file which defines some initial key-bindings (for things like | menus) and a few style options, as well as mouse-bindings (needed to | display buttons on the titlebar anyway). In addition, this file also | defines some of the internal functions such as WindowListFunc. Often is the | case that one's own ~/.fvwm2rc file overrides some aspects of this anyway. | | Once it's done that, then FVWM goes on to look for *one* of the following | files in the order listed, using whichever one comes first: | | $HOME/.fvwm/config | /usr/local/share/fvwm/config | | $HOME/.fvwm/.fvwm2rc | $HOME/.fvwm2rc | /usr/local/share/fvwm/.fvwm2rc | /usr/local/share/fvwm/system.fvwm2rc | /etc/system.fvwm2rc | | As for titlebar removals, you'd need to do that via Style lines in your | ~/.fvwm/config file (since you're using FVWM 2.5.21) a la: | | Style foo !Title, !Borders | | etc... | | Note that deleting your ~/.fvwm/ directory means nothing -- FVWM only | recreates it anyway. Yes I understand that ~/.fvwm is re-created when FVWM starts; however since I had deleted mine (actually moved it to ~/.fvwm.save) there's no config file in it. Nor is there any config file in any of the places in the group you list 11 to 18 lines above. So it just reads the "ConfigFvwmDefaults" file (which is actually, on my machine, "/usr/share/fvwm/ConfigFvwmDefaults"). OK, so I will try adding lines (a few lines at a time) and see when things break. Does that sound like a good strategy? (Thanks for telling me about "ConfigFvwmDefaults".) Another possible strategy might be to pull some key lines from "ConfigFvwmDefaults" (I see, for example, sections labeled "# Needed by the ewmh support", and "# Needed by modules which use session management") and insert them into my own config file. Any idea what sections might be key? | | > 2. I don't think my config file is at fault, however, since if I | > replace my config file with, say, system.fvwm2rc, or | > system.fvwm2rc-sample-1 (samples that are in the fvwm source distro) | > it also does NOT work. | | Which means you can't be forcing FVWM to run under a session manager at all. | What steps are you undertaking to try and do this? OK, what I did was to copy system.fvwm2rc from its location in the source code directory to ~/.fvwm/ (renaming it "config"), then log on in the usual way for gnome (gnome session with metacity as WM), then, from a gnome-terminal, issue the command "fvwm -s 0 --replace". It is at this point that things go awry, with fvwm seeming to start correctly with a few flashing windows (with correct title bars) and an FvwmButtons panel, then both the title bars and the FvwmButtons disappear and I am left in the inoperable state I described earlier. (I also tried the slightly longer method, involving changing metacity to "normal" in the sessions panel (+ apply) then issuing the command killall metacity; sleep 2; fvwm &), but neither method works.) What I'm saying is that the above process leads to problems whenever I have either my own config or a sample config in ~/.fvwm, but that things work correctly if there is no config file to be found in the above list of places (and an error message appears on the screen with that list, saying no config file found). So I guess ConfigFvwmDefaults works. I will try putting THAT file in ~/.fvwm (renaming it config) and see if that works. | | > (Maybe there are other ways to accomplish this, but the above works for | > me.) | | A little dated now, but see: | | http://linuxgazette.net/100/adam.html | yes thanks for this ref, and for your good suggestions. -- peter | | -- Thomas Adam | | -- | "He wants you back, he screams into the night air, like a fireman going | through a window that has no fire." -- Mike Myers, "This Poem Sucks". |
Re: FVWM: Window placement
On Wed, 2007-07-25 at 21:41 +0200, Dominik Vogt wrote: > > > > Try > > > > Style ... FixedUSPosition, FixedPPosition > > Style ... !UsePPosition, !UseUSPosition > > Style ... FixedUSSize, FixedPSize > > > > If that helps, try removing some of the styles. > > And if it does not help, try out the latest code from CVS. Fvwm > was ignoring the Fixed... styles in one specific EWMH message. I > have fixed that. I haven't used CVS, so I'm not certain that I'd be grabbing the entire release. Is there an un-stable release due out soon?
Re: FVWM: Window placement
> > Style ... FixedUSPosition, FixedPPosition > > Style ... !UsePPosition, !UseUSPosition > > Style ... FixedUSSize, FixedPSize > > > > If that helps, try removing some of the styles. > > It semi-worked with all three style lines added. > However, after placing the window, I could not move it. > > I removed the first style line above and the window > warped back to the center of the screen. It's beginning to sound as if FVWM may need to add an "IgnoreAllClientPlacement" style to handle this sort of client breakage :(
Re: FVWM: Window placement
On Wed, 2007-07-25 at 21:11 +0200, Dominik Vogt wrote: > Try > > Style ... FixedUSPosition, FixedPPosition > Style ... !UsePPosition, !UseUSPosition > Style ... FixedUSSize, FixedPSize > > If that helps, try removing some of the styles. It semi-worked with all three style lines added. However, after placing the window, I could not move it. I removed the first style line above and the window warped back to the center of the screen.
Re: FVWM: Window placement
On Wed, Jul 25, 2007 at 09:11:51PM +0200, Dominik Vogt wrote: > On Tue, Jul 24, 2007 at 03:41:30PM -0400, Ryan Daly wrote: > > On Tue, 2007-07-24 at 20:25 +0100, Thomas Adam wrote: > > > On Tue, Jul 24, 2007 at 03:22:27PM -0400, Ryan Daly wrote: > > > > It's the Black Box ServSelect IP Software. I'm 99% certain it is a Java > > > > application. > > > > > > That doesn't surprise me. Java's a bag of crap. > > > > > > > I tried the above and the only difference is that I cannot move the > > > > window once it warps back to the center of the screen. > > > > > > Ah, damn -- so it's placement _really_ does want to be in the centre of > > > the > > > screen then? That's not good at all. > > > > No, and I gather from your disgust that there's no way to get around it, > > either? > > Try > > Style ... FixedUSPosition, FixedPPosition > Style ... !UsePPosition, !UseUSPosition > Style ... FixedUSSize, FixedPSize > > If that helps, try removing some of the styles. And if it does not help, try out the latest code from CVS. Fvwm was ignoring the Fixed... styles in one specific EWMH message. I have fixed that. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: Window placement
On Tue, Jul 24, 2007 at 03:41:30PM -0400, Ryan Daly wrote: > On Tue, 2007-07-24 at 20:25 +0100, Thomas Adam wrote: > > On Tue, Jul 24, 2007 at 03:22:27PM -0400, Ryan Daly wrote: > > > It's the Black Box ServSelect IP Software. I'm 99% certain it is a Java > > > application. > > > > That doesn't surprise me. Java's a bag of crap. > > > > > I tried the above and the only difference is that I cannot move the > > > window once it warps back to the center of the screen. > > > > Ah, damn -- so it's placement _really_ does want to be in the centre of the > > screen then? That's not good at all. > > No, and I gather from your disgust that there's no way to get around it, > either? Try Style ... FixedUSPosition, FixedPPosition Style ... !UsePPosition, !UseUSPosition Style ... FixedUSSize, FixedPSize If that helps, try removing some of the styles. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: suddenly: a gnome-fvwm conflict problem
On Wed, Jul 25, 2007 at 11:52:02AM -0700, Peter Scott wrote: > 1. If I delete $HOME/.fvwm (so my config file is gone) then fvwm starts > under the gnome-session, although it complains about not being able to > find a config (or .fvwm2rc) file. (What does fvwm use for a config in > that case? I have no idea.) Of course then I get crummy titlebars > (even over the gnome panels) etc., which I have no idea how to fix. OK, here's what FVWM does. (Why some of this isn't documented is beyond me). When FVWM loads it loads a *minimal* internal set of commands -- just the barebones so that *something* happens. Once that is done, it then goes on to read: $(fvwm-config -d)/ConfigFvwmDefaults It's *this* file which defines some initial key-bindings (for things like menus) and a few style options, as well as mouse-bindings (needed to display buttons on the titlebar anyway). In addition, this file also defines some of the internal functions such as WindowListFunc. Often is the case that one's own ~/.fvwm2rc file overrides some aspects of this anyway. Once it's done that, then FVWM goes on to look for *one* of the following files in the order listed, using whichever one comes first: $HOME/.fvwm/config /usr/local/share/fvwm/config $HOME/.fvwm/.fvwm2rc $HOME/.fvwm2rc /usr/local/share/fvwm/.fvwm2rc /usr/local/share/fvwm/system.fvwm2rc /etc/system.fvwm2rc As for titlebar removals, you'd need to do that via Style lines in your ~/.fvwm/config file (since you're using FVWM 2.5.21) a la: Style foo !Title, !Borders etc... Note that deleting your ~/.fvwm/ directory means nothing -- FVWM only recreates it anyway. > 2. I don't think my config file is at fault, however, since if I > replace my config file with, say, system.fvwm2rc, or > system.fvwm2rc-sample-1 (samples that are in the fvwm source distro) > it also does NOT work. Which means you can't be forcing FVWM to run under a session manager at all. What steps are you undertaking to try and do this? > (Maybe there are other ways to accomplish this, but the above works for > me.) A little dated now, but see: http://linuxgazette.net/100/adam.html -- Thomas Adam -- "He wants you back, he screams into the night air, like a fireman going through a window that has no fire." -- Mike Myers, "This Poem Sucks".
FVWM: suddenly: a gnome-fvwm conflict problem
Although I have been using fvwm as a window manager under gnome for years (and much appreciating its excellent attributes), suddenly two days ago (perhaps after altering some permissions in /tmp, trying to get k3b to work properly, and maybe upgrading about four or five packages) I found an odd problem when trying to start fvwm in a running gnome-session. I am using Fedora 7, with the fvwm-2.5.21-4.fc7.1 package that came with it (wow was I surprised to see fedora now ships fvwm). When I installed F7 about a month ago everything worked smoothly; all I had to do was to give the "fvwm -s 0 --replace" command and since I had created $HOME/.fvwm with my config file in it, everything worked, metacity was replaced by fvwm and I was swimming again. Sessions are saved, and subsequent logins start the gnome-session with fvwm as the window manager, just as advertised. Right now, however, the fvwm session has ceased to work; windows (like xterm or gnome-terminal) are sans title bars and unusable, the FvwmButtons panel flashes on and then disappears, the gnome panels are gone, and about all I can do from such a state is to hit CTRL-ALT-BACKSPACE to get back to my login screen. However there are ways some things do (or do not) work: 1. If I delete $HOME/.fvwm (so my config file is gone) then fvwm starts under the gnome-session, although it complains about not being able to find a config (or .fvwm2rc) file. (What does fvwm use for a config in that case? I have no idea.) Of course then I get crummy titlebars (even over the gnome panels) etc., which I have no idea how to fix. 2. I don't think my config file is at fault, however, since if I replace my config file with, say, system.fvwm2rc, or system.fvwm2rc-sample-1 (samples that are in the fvwm source distro) it also does NOT work. 3. I can log on with bare fvwm (no gnome) and that works, and then I can start a gnome-session after fvwm is working (with my config). As long as I don't kill the window from which I started gnome-session I have a usable system. Since I don't want the gnome desktop to act as a barrier to my root window I do the following: (a) In System-->Preferences-->Personal-->Sessions change the nautilus from "restart" to "normal" and apply; (b) issue the command "pkill bonobo"; (c) issue the command "killall nautilus; sleep 2; nautilus --no-desktop &" (Maybe there are other ways to accomplish this, but the above works for me.) But I would like to be able to run fvwm under gnome-session and not the other way around. Does anyone have any idea what might be happening? Is this an EWMH issue? What could have possibly changed in my system to have caused this problem? What should I try? Has anyone else experienced this behavior? -- Peter
