Subject: FVWM: questions about fvwm-snap-19990716

From: Paul Johnson <[email-masked]>
Date: Wed, 04 Aug 1999 14:24:29 -0500

I noticed the fvwm2 I was using in Redhat 6 was not Gnome-aware, so I
found a snap and built it.  You have done a nice job. The desktops "map"
correctly and the funky behaviors I was experiencing with all apps
wanting to start on desktop 0 are gone.

I've come up with 2 usage problems, hope you could explain.
1. I had configured the alt-mouse1 key to move windows. This is a
standard window maker config that I like lots. It worked fine in
fvwm2-2.2.2, but in the snapshot, it has the funny behavior that it does
not work if I leave the alt key depressed after clicking. If I let the
alt key up and the mouse button up, then a transparent window frame
appears and I can move the window.

Is it possible to make it work the old way?

2.  My configuration was set so FvwmButtons would launch at startup.  It
no longer runs at start time. I can launch it within the session.  Is
there something about the gnome configuration that blocks having modules
at start time?

(I know, you think I ought to use Gnome stuff instead of FvwmButtons,
but I spent so much time on the configuration of it that I want to keep
using it.).
-- 
Paul E. Johnson                       email: [email-masked]
Dept. of Political Science            http://lark.cc.ukans.edu/~pauljohn
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66045                FAX: (785) 864-5700
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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: Dominik Vogt <[email-masked]>
Date: Thu, 5 Aug 1999 07:05:29 +0200

> Is it possible to make it work the old way?

With current development code I have no problem to make this work.
I use this binding:

  mouse 1 w m move

As soon as I release the button the move operation starts, regardless
of the state of the meta key. Can you check this with a current snapshot?

> there something about the gnome configuration that blocks having modules

I guess you're starting FvwmButtons directly from the config file.
Try putting the line in your InitFuction/RestartFunction.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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: Paul Johnson <[email-masked]>
Date: Thu, 05 Aug 1999 11:14:01 -0500

Dominik Vogt wrote:

> of the state of the meta key. Can you check this with a current snapshot?

That is what I am calling the problem. In 2.2.2, the move operation
begins with the click, not the release of the meta key.  What you
describe is a new behavior. I could probably get used to it, but I don't
like it because it is not consistent with the Window Maker behavior I'm
trying to immitate.  Also, the meta key behavior is not consistent
across actions within fvwm2. For example, to resize I use
meta-rightclick.  With that one, the meta key can be held down while
resizing.  Here are the key bindings I use

Mouse 1 A       M      Move
Mouse 3 A       M      Resize

> Try putting the line in your InitFuction/RestartFunction.

I have this.  Why is it not working?

AddToFunc InitFunction    "I" Module FvwmButtons
+                         "I" exec xsetroot -mod 2 2 -fg \#554055 -bg
\#705070
AddToFunc RestartFunction "I" Module FvwmButtons
+                         "I" exec xsetroot -mod 2 2 -fg \#554055 -bg
\#705070

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 5 Aug 1999 12:58:37 -0400

> +                         "I" exec xsetroot -mod 2 2 -fg \#554055 -bg

Along with the gnome support is support for session managment and that
may be causing your problems.  You can to do too things confirm that
the InitFunction is actually wunning (i.e. is the xsetroot working).  I
beleive something called SessionInitFunction and SessionRestartFunction
was added, so if you have a session manger, or fvwm thinks you have a
session manager then you want to use this.

Brad
 
-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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: Dominik Vogt <[email-masked]>
Date: Fri, 6 Aug 1999 05:59:41 +0200

> resizing.  Here are the key bindings I use

Somehow a fix I made last year has disappeared again. I have fixed it
in the development tree, but this fix won't apply to the 2.2.2 sources.
If you have the sources you can make this patch:

In the file fvwm/add_window.c you'll find this passage:

  #if 0
	    XGrabButton(dpy,(i),0,tmp_win->frame,True,
			ButtonPressMask, GrabModeSync,GrabModeAsync,None,
			Scr.FvwmCursors[SYS]);
	    XGrabButton(dpy,(i),LockMask,tmp_win->frame,True,
			ButtonPressMask, GrabModeSync,GrabModeAsync,None,
			Scr.FvwmCursors[SYS]);
  #else

Replace the '#if 0' with '#if 1' and your problem should be solved.
I am not sure why this fix has been commented out again, but in the
ChangeLog there is the following entry:

	* fvwm/add_window.c (AddWindow): backed out a patch that caused a mouse
	binding problem

I guess this causes a problem somewhere else, so I won't make
any guarantees.

Bye

Dominik ^_^