Subject: FVWM: FvwmAuto: bugs and suggestions

From: Neil Zanella <[email-masked]>
Date: Mon, 10 Aug 1998 20:46:25 -0230 (NDT)

Hello,

I have bound the FvwmAuto autoraise module to all window's titlebar button #2 
mouse button #2, and I think it's handy because I use the module quite often.

Since I am equally likely to use the module as to get fed up of it while running
fvwm2, I also bound a function that kills the module to button #2 mouse 
button #3, but to save buttons I would like button #2, mouse button #2 to
activate the module if it is not running and deactivate it if it is running.

This I think requires some sort of conditional structure in defining an Fvwm
function which I don't think is present in Fvwm right now.
So, could this functionality perhaps be added in the future?

I know I can have up to 10 buttons but I really don't like a cluttered titlebar.

After all, a window manager is all about look and feel isn't it?

----

Now, another thing, when I click on the button to activate the module the button

does not seem to go down for 1/6 of a second or anything which looks bad cause

it looks as if one never clicked on anything while in fact an action was 

invoked.

----

Also, the conditional statement functionality mentioned above should also prevent

me from activating multiple FvwmAuto modules (why would one need more than one

running? We need to include this because each module started needs to be killed 

separately, which can be tedious in this case, other than the fact that the 

modules would be taking up space for nothing.)

Best regards,

Neil

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Bob Woodside <[email-masked]>
Date: Tue, 11 Aug 1998 01:18:52 -0400 (EDT)

> activate the module if it is not running and deactivate it if it is running.

        Hmmm. I'd think that this would be better put in your top level menu,
or in a button bar - though I can sympathize if you don't want your desktop
cluttered with button bars and such; I only bring my button bar up on
special occasions. Logically, it would seem more appropriate to bind
window-specific things to the window decorations. But, that's your choice.

> This I think requires some sort of conditional structure in defining an 
> Fvwm function which I don't think is present in Fvwm right now.

        Possibly, but a revised Fvwm command language is probably a good
bit in the future. Instead of waiting around for that, why not try a bit
of ingenuity? You can do what you want with a little shell script that
interacts with Fvwm via FvwmCommand. Here's how you do it.

        First, bind whatever you like to a function you define in your
fvwm2rc, something like

        AddToFunc  ToggleAutoFunc
+                  "I"       Module FvwmCommandS
+                  "I"       Exec exec MyToggleAutoScript

        Next, you write MyToggleAutoScript in the language of your choice -
Bourne shell, Perl, Tcl, whatever. This script should

        1. Wait till it sees FvwmCommandS active
        2. Check whether FvwmAuto is active
        3. If FvwmAuto is active, send a KillModule command via FvwmCommand
        4. If it is not active, send a Module FvwmAuto command via FvwmCommand
        5. Wait for a respectable interval, and use FvwmCommand to send
           the command "KillModule FvwmCommandS"

(Of course, some people like to keep FvwmCommandS active all the time, which
would simplify the script, but why waste resources?)

        I know it's fashionable to argue for a new Fvwm command language 
that's a full programming language, but you'd be surprised what you can do
without that, using the facilities that exist now.

> ----
> 
> Now, another thing, when I click on the button to activate the module the
> button does not seem to go down for 1/6 of a second or anything which looks
> bad cause it looks as if one never clicked on anything while in fact an
> action was invoked.

        Strange, mine do. I think it depends on what kind of buttons you're
using - a very flat looking button may not show much difference, if any, or
it could have to do with the color scheme you specify for the window 
decorations - and I'm not sure what happens if you use mini-icon style 
buttons.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 11 Aug 1998 10:40:26 +0100

Neil Zanella wrote:
> .........., but to save buttons I would like button #2, mouse button #2 to

How about binding the following function to the button
AddToFunc ToggleAuto	"I" FvwmAuto 500
+			"I" Exec shell_script_to_kill_FvwmAuto_if_more_than_one

The shell_script_t.... will depend on your operating system but can run
a ps, grep, wc to count the number of FvwmAuto modules running and kill
them all if there is more than one.

> does not seem to go down for 1/6 of a second or anything which looks bad cause

This might be the way you have written your functions causing fvwm to
wait for the ClickTime (150ms) to work out if you are clicking or
dragging.  If you write your functions thus:

AddToFunc blahblah	"I" whatever
+			"I" whatever

then fvwm will not wait for ClickTime and will do whatever immediately. 
If you write them:

AddToFunc blahblah
+ "I" whatever
+ "I" whatever

it will wait even though you haven't got any "M", "C" or "D" lines in
the function.

Hope this helps,
Tim.

---

From: Neil Zanella <[email-masked]>
Date: Tue, 11 Aug 1998 08:57:26 -0230 (NDT)

> window-specific things to the window decorations. But, that's your choice.

You have a point here. The thing is that it is very easy to click on window titlebar

buttons because they are always in reach. So, for something I use so often as that I thought

a button binding would be OK. With my 4 buttons per window I can do 12 different things, so

really, I do have buttons to spare, and though not as intuitive as having this option in a menu,

it is much quicker.I prefer to use menus for applications instead (eg, pine, netscape, xxgdb, xclock,

xbiff, top, rsh, ftp, etc...)

> without that, using the facilities that exist now.

Your suggestion is very neat and would probably do for now. It would be nice though

to be able to keep everthing in one file and not in a .fvwm2rc and a .sh file.

Thanks for your help,

Neil

---

From: Bob Woodside <[email-masked]>
Date: Tue, 11 Aug 1998 21:09:42 -0400 (EDT)

On 11-Aug-98 Neil Zanella wrote:

> You have a point here. The thing is that it is very easy to click on window
> titlebar buttons because they are always in reach. So, for something I use
> so often as that I thought a button binding would be OK.

        That's the whole point of the X philosophy - flexibility to customize
your desktop in a way that lets you work comfortably and efficiently, not
necessarily the same way everyone else does. Go for it.

> Your suggestion is very neat and would probably do for now. It would be 
> nice though to be able to keep everthing in one file and not in a .fvwm2rc
> and a .sh file.

        Quite right, it would. However, I believe it will be a while before
the developers reach a consensus about what's to be done with Fvwm's command
language, and there are some significant architectural changes that really
need to be made - e.g., the famous Great Style Flag Rewrite (tm) - before
serious work is done on the command language. Also, Fvwm is in a state of
transition between the old and the new maintainer, which slows things down
a bit.

        That's why I suggested a technique you can use right now to get the
result you want. 

        Oh, yes. That one file. (I know, I'm shifting the emphasis of your
remark slightly.) You'll probably find, as you add enough stuff to that one
.fvwm2rc file, that it'll become *really* unmanageable, and you'll want to
split it into several smaller ones sourced by the main file. My present
.fvwm2rc is little more than a bunch of Read commands to pull in the various
other pieces, that are of a convenient editing size.

---

From: Patrick Rogan <[email-masked]>
Date: Tue, 11 Aug 1998 23:02:14 -0400

I really want to set autoraise on a per-window(application) basis.

After spending a lot of attention porting and tweeking my wm enviroment,
I realised that with Netscape, autoraise (follows mouse) would be a
definate benifit.  Normally I LOATHE autoraise, but watching myself use
netscape, I spend a LOT of time switching between windows.  I went to
set AutoRaise on for just Netscape like all the other Styles, but found
that it had been changed into a module...  

It does not look like i can set autoraise on a per-application basis, am
I right?

I would really like to be able to do this.  Other windowmanagers let you
autoraise just the panner, for example (ctwm???).  

WHAT IF...  AutoRaise'ing a StaysOnBottom window causes it to jump to
the top of the windowlist while the mouse is over it, then pops back
down to the bottom when the mouse rolls off of it...

~p@

---

From: Tim Phipps <[email-masked]>
Date: Wed, 12 Aug 1998 08:48:54 +0100

> I really want to set autoraise on a per-window(application) basis.
You can do it indirectly with a conditional function.  e.g.

FvwmAuto 500 EnterFunc 

AddToFunc EnterFunc "I" Current [Netscape] Raise
+ "I" Current [SomeOtherAutoraiseAppClass] Raise
+ "I" Next [CurrentDesk *StaysOnBottom*] Lower

This should also keep anywindows on the bottom that have StaysOnBottom
in their name or icon title, it's a bit of a hack but most apps can be
given a title and if you set the style to have no title bar then you
might not notice.

Cheers,
Tim.