Re: FVWM: Undoing the default fvwm behavior

2009-01-26 Thread Tom Panning
On Mon, Jan 26, 2009 at 1:15 PM, Thomas Adam thomas.ada...@gmail.com wrote:
 2009/1/26 Tom Panning lurc...@gmail.com:
 All,

 By default, fvwm sets MouseFocus, adds titles and borders, provides
 pages, etc. I want to start out with fvwm doing exactly what X does
 without a window manager, and then I'll add behaviors for specific
 applications. I have to do this because most of the applications on my
 platform don't expect a window manager to be present (and a window
 manager would mess them up), but I want to add a few applications that
 could use window management. I've started by using the commands:

 Then you have very odd applications indeed.  But I will humour you 
 nevertheless.

 Basically, if you removed every config file FVWM tried to read, it
 would still give you some level of decoration as that functionality is
 *builtin* to FVWM (see fvwm.c:SetRCDefaults()).  So, let's assume you
 do this:

 mv $(fvwm-config -d) /somewhere/else
 fvwm -f /dev/null

 Then you're pretty close.   Basically, FVWM will source $(fvwm-config
 -d)/ConfigFvwmDefaults before going on to look for your user specified
 config.  To truly make sure nothing in fvwm's datadir is ever sourced,
 we move it out of the way.  Then, passing in an option to FVWM to use
 /dev/null as its config leaves nothing but what's defined in
 SetRCDefaults() but these should be sufficient for you.

 I still question *why* you think you need to do this though.

Thank you very much. The config file ConfigFvwmDefaults and the
function SetRCDefaults() were what I was looking for. As for why I
need this, the platform that I'm working on currently has no window
manager at all. The programs written for it handle their own window
management and assume that the user can't interfere with the window
management. Recently, we've wanted to add a generally available
application that assumes that there will be a window manager to handle
focus, borders, etc. So we want most of the applications to continue
to do their own management (eventually they may be modified to work
with a window manager), but we want the new application to have normal
window management. If you know of other ways to achieve this, I'd be
happy to try them.

As an aside, I tried using the Unmanaged style. I was unable to find a
way to allow the unmanaged windows to be raised above the managed
windows and vice versa (setting RaiseOverUnmanaged allowed me to have
one or the other, but not both).

Thanks for you interest,
Tom



Re: FVWM: Undoing the default fvwm behavior

2009-01-26 Thread Thomas Adam
2009/1/26 Tom Panning lurc...@gmail.com:
 As an aside, I tried using the Unmanaged style. I was unable to find a
 way to allow the unmanaged windows to be raised above the managed
 windows and vice versa (setting RaiseOverUnmanaged allowed me to have
 one or the other, but not both).

Of course not -- they're unmanaged -- that means once FVWM has been
told to ignore that window, then that's that.  Raising that window
would have to be a facet of FVWM's management, and how can it do that
when you've told it not to manage that window?

-- Thomas Adam



Re: FVWM: Undoing the default fvwm behavior

2009-01-26 Thread Tom Panning
On Mon, Jan 26, 2009 at 3:39 PM, Thomas Adam thomas.ada...@gmail.com wrote:
 2009/1/26 Tom Panning lurc...@gmail.com:
 As an aside, I tried using the Unmanaged style. I was unable to find a
 way to allow the unmanaged windows to be raised above the managed
 windows and vice versa (setting RaiseOverUnmanaged allowed me to have
 one or the other, but not both).

 Of course not -- they're unmanaged -- that means once FVWM has been
 told to ignore that window, then that's that.  Raising that window
 would have to be a facet of FVWM's management, and how can it do that
 when you've told it not to manage that window?

Sorry, I didn't mean that as a complaint. I was just pointing it out
in case someone suggested using the Unmanaged style (since I said that
I didn't want certain windows to be managed). And I didn't think of
calling XRaiseWindow() from another program as part of FVWM's window
management since it will work when there is no window manager running,
although I understand that the raise request goes to the window
manager if one exists.

Tom