Subject: FVWM: Strange AddToFunc behavior

From: Kirk Hilliard <[email-masked]>
Date: 29 Jan 1998 12:00:55 -0500

The ChangeLog for fvmw2 version 2.0.46 includes:

       37. Focus command no longer raises - use an interpreted
           focus-and-raise function if that's desired

My first attempt at such a function was this:

  # The Focus command no longer raises the window automatically.
  # Here is a function that emulates the old Focus behavior.
  DestroyFunc focus-and-raise
  AddToFunc   focus-and-raise
  +                           "I" Focus
  +                           "I" Raise
  
  # And here are the new bindings.
  Key Tab         A       M       Next [CurrentDesk] focus-and-raise
  Key Tab         A       MS      Prev [CurrentDesk] focus-and-raise

This function did focus and raise the next window, but then focus
immediately returned to the window under the mouse.  (This would
probably not have been the case with ClickToFocus -- I use
SloppyFocus.)

I then discovered that by defining the function like this:

  # The Focus command no longer raises the window automatically.
  # Here is a function that emulates the old Focus behavior.
  DestroyFunc focus-and-raise
  AddToFunc   focus-and-raise "I" Focus
  +                           "I" Raise

it worked as I expected -- the focus remained with the newly raised
window and did not return to the window under the mouse.  Also, this
second form results in a much faster function -- one which can keep up
with my keyboard repeat rate if I hold down Alt-Tab.  The first
function is considerably slower, with a visible delay between the time
that the next window is raised and it shifts color to indicate that it
has focus.  (This is easier to see when the mouse is moved to the root
window so that focus stays with the newly raised window.)

Is this a bug or a feature?  I initially chose this first style
because it is used in the Debian system.fvwm2rc.  I now see that the
fvwm2 man page only shows the second style for AddToFunc, but it does
not warn against the first style, and that style is used for
AddToDecor.

Kirk Hilliard
--
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: Dan Espen <[email-masked]>
Date: Fri, 30 Jan 1998 10:14:39 -0500

> probably not have been the case with ClickToFocus -- I use
...
> it worked as I expected -- the focus remained with the newly raised
...
> not warn against the first style, and that style is used for

I think I can  say, "I'm sorry I looked".   Well, its not  really that
bad...

Not only  is "AddToDecor" documented to  work like this, but there are
some   "AddToFunc"   examples      that   look    like   this       in
sample.fvwmrc/decor_examples.  (Ie.  the "action" is  missing from the
first definition line.)

A quick look at the code seemed to show that AddToFunc, AddToMenu, and
AddToDecor all seem to use the same parsing  logic, so they should all
follow the same syntax rules.

They all seem to ignore the fact that the "action" part of the command
is  missing from the first line,  and  store away  a  blank action for
later use.

In  the case of   AddToFunc,  the  function  later  gets  executed  in
complex.c:ComplexFunction().  This function expects the first token to
be "D" (DOUBLE_CLICK), "I" (IMMEDIATE),  or it assumes it's some other
valid value that turns on a flag that looks to  me like it will try to
defer execution  of the command.  Perhaps   that explains the reported
symptom.

I'd  vote for making "AddToFunc" without  an action valid syntax since
it seems to be  pretty natural.  If this isn't  fixed after  2.0.47, I
might be willing to give it a stab.

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
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].