Re: FVWM: suddenly: a gnome-fvwm conflict problem

2007-07-25 Thread Peter Scott
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

2007-07-25 Thread Thomas Adam
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

2007-07-25 Thread Peter Scott
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

2007-07-25 Thread Ryan Daly
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

2007-07-25 Thread Perry Hutchison
> >   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

2007-07-25 Thread Ryan Daly
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

2007-07-25 Thread Dominik Vogt
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

2007-07-25 Thread Dominik Vogt
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

2007-07-25 Thread Thomas Adam
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

2007-07-25 Thread Peter Scott
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