Subject: Re: FVWM: Fvwm configuration questions: ClickToRaise & WindowName style

From: Elad Eyal <[email-masked]>
Date: Sun, 1 Dec 1996 14:54:54 +0200 (IST)

Good morning,

[Please reply this to [email-masked]. I'm not on the list]

> > 	The first issueis really annoying: Under MWM (which came
> > preconfigured from the gods, more or less), the focus went wherever the
> > mouse was, and a mouse click on a mouse caused it to raise. I tried to
> > achieve a similiar affect using "Mouse 1 W A Raise" and it worked, only
> > that the mouse click never arrived to the application in the window. Not
> > good, not good. Anyone can help me with this, please?
> 
> Your description of the desired behavior is a little bit ambiguous, so
> I am not quite sure that I understand you. 

Yes, because I used a phrase like "click on a mouse" which should have
been a "window".

Let's say I have a window B which is half hidden behind a window A. I move
the mouse into window B and then focus changes to window B. Cool. Now I
want to raise window B. Under MWM I could click anywhere within window B
and it would be raised (and the click passed to application). Under FVWM
(95, v2.0.42) I must click on the border or on the title for the window to
raise. I use SloppyFocus which I like very much. I don't want
ClickToFocus. ANy help?

> Style "*"            SloppyFocus
> Style "*"            ClickToFocus
> Style "*"            MouseFocus
> You should also investigate, whether you want to (de)install FvwmAuto.

Tried it, been there, seen 'em all. No help. I even considered changing
FvwmAuto so it would do what I want but apparantly Modules are not
notified on clicks within the window.

I also tried "Mouse 1 W A Raise" but then a click would raise the window
but not allow for the click to arrive the underlying program (within the
window).

> Use the "Identify" command to figure out the names of your

OK, Here's one example window, which is used for my local workstation
called 'cream'.
Identify command says:
		Name: [cream]
		Icon Name: [cream]
		Class: XTerm
		Resource: xterm

At the FvwmTalk window I type:   Style "[cream]" color green/yellow
and then do "recapture". Nothing happens. If I do "XTerm" instead of
"[cream]" it works. I want to assign different colors to the title bars,
and differet mini-icons according to the window name.

I think the "-name" option to XTREM does the trick. Unfortunately I'm late
to be somewhere so I'll have to check it later. The script I'm using today
sents (as far as I can tell by checking the source) only -T (and -fg, -bg)

PS: I have to admit it's been a long while since I last replied such a
thorough and polite answer to a list query. Way To Go.

 _
(_  /  _    /          ( E-mail pigeons nest in binary trees )
(__/__(/\_(/

--
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: "Randall S. Winchester" <[email-masked]>
Date: Sun, 1 Dec 1996 09:03:25 -0500 (EST)

I have had the same problem. Ths closest I could get was:

# In the Window the modifier key (usually alt or diamond) does a raise.
#     Button    Context Modifi  Function
Mouse 1         W       M       Raise

I did not know MWM worked the way you described. I myself use Win95 from
home with Xwin32, and Xmouse, where I am used to similar behaviour. 

Howver if anyone knows how to get a single mouse click in a window area to
raise the window, without loosing the "cut (from cut and paste)
functionality, I would be grateful. 

Randall

On Sun, 1 Dec 1996, Elad Eyal wrote:

: Good morning,
: 
: [Please reply this to [email-masked]. I'm not on the list]
: 
: > > 	The first issueis really annoying: Under MWM (which came
: > > preconfigured from the gods, more or less), the focus went wherever the
: > > mouse was, and a mouse click on a mouse caused it to raise. I tried to
: > > achieve a similiar affect using "Mouse 1 W A Raise" and it worked, only
: > > that the mouse click never arrived to the application in the window. Not
: > > good, not good. Anyone can help me with this, please?
: > 
: > Your description of the desired behavior is a little bit ambiguous, so
: > I am not quite sure that I understand you. 
: 
: Yes, because I used a phrase like "click on a mouse" which should have
: been a "window".
: 
: Let's say I have a window B which is half hidden behind a window A. I move
: the mouse into window B and then focus changes to window B. Cool. Now I
: want to raise window B. Under MWM I could click anywhere within window B
: and it would be raised (and the click passed to application). Under FVWM
: (95, v2.0.42) I must click on the border or on the title for the window to
: raise. I use SloppyFocus which I like very much. I don't want
: ClickToFocus. ANy help?
: 
: > Style "*"            SloppyFocus
: > Style "*"            ClickToFocus
: > Style "*"            MouseFocus
: > You should also investigate, whether you want to (de)install FvwmAuto.
: 
: Tried it, been there, seen 'em all. No help. I even considered changing
: FvwmAuto so it would do what I want but apparantly Modules are not
: notified on clicks within the window.
: 
: I also tried "Mouse 1 W A Raise" but then a click would raise the window
: but not allow for the click to arrive the underlying program (within the
: window).
: 
: > Use the "Identify" command to figure out the names of your
: 
: OK, Here's one example window, which is used for my local workstation
: called 'cream'.
: Identify command says:
: 		Name: [cream]
: 		Icon Name: [cream]
: 		Class: XTerm
: 		Resource: xterm
: 
: At the FvwmTalk window I type:   Style "[cream]" color green/yellow
: and then do "recapture". Nothing happens. If I do "XTerm" instead of
: "[cream]" it works. I want to assign different colors to the title bars,
: and differet mini-icons according to the window name.
: 
: I think the "-name" option to XTREM does the trick. Unfortunately I'm late
: to be somewhere so I'll have to check it later. The script I'm using today
: sents (as far as I can tell by checking the source) only -T (and -fg, -bg)
: 
: PS: I have to admit it's been a long while since I last replied such a
: thorough and polite answer to a list query. Way To Go.
: 
: 
:  _
: (_  /  _    /          ( E-mail pigeons nest in binary trees )
: (__/__(/\_(/
: 
: 
: --
: 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: Elad Eyal <[email-masked]>
Date: Sun, 1 Dec 1996 18:34:54 +0200 (IST)

Good morning,

> functionality, I would be grateful. 

... And without losing MouseFocus..!

 _

---

From: Markus Gutschke <[email-masked]>
Date: 04 Dec 1996 23:56:06 +0100

> ... And without losing MouseFocus..!

I think, I finally understand what you are trying to achieve. As I
could not find a solution that required changes to my .fvwmrc, only. I
had a look at the C source code and came up with a little
patch. Please note, that I do not really have a clue of what I am
doing ;-) I hope, Chuck won't kill me for introducing this
hack... OTOH, maybe it is a proper solution?

Markus

--- fvwm/add_window.c.orig	Thu Apr 11 17:25:58 1996
+++ fvwm/add_window.c	Wed Dec  4 23:41:13 1996
@@ -492,8 +492,10 @@
 			&a,&b,&JunkChild);
   tmp_win->xdiff -= a;
   tmp_win->ydiff -= b;
+#ifdef SUPPRESS_CLICKTORAISE
   if(tmp_win->flags & ClickToFocus)
     {
+#endif
       /* need to grab all buttons for window that we are about to
        * unhighlight */
       for(i=0;i<3;i++)
@@ -506,7 +508,9 @@
 			ButtonPressMask, GrabModeSync,GrabModeAsync,None,
 			Scr.FvwmCursors[SYS]);
 	  }
+#ifdef SUPPRESS_CLICKTORAISE
     }
+#endif
   BroadcastConfig(M_ADD_WINDOW,tmp_win);
 
   BroadcastName(M_WINDOW_NAME,tmp_win->w,tmp_win->frame,
--- fvwm/events.c.orig	Mon May 27 21:33:26 1996
+++ fvwm/events.c	Wed Dec  4 23:46:03 1996
@@ -1030,6 +1030,25 @@
 
 	}
     }
+
+#ifndef SUPPRESS_CLICKTORAISE
+  else if ((Tmp_win) && !(Tmp_win->flags & ClickToFocus) &&
+	   Event.xbutton.window == Tmp_win->frame)
+    {
+	  if (Tmp_win != Scr.LastWindowRaised &&
+	      ((Event.xbutton.state&
+		(ControlMask|Mod1Mask|Mod2Mask|Mod3Mask|Mod4Mask|Mod5Mask))
+	       == 0)) {
+	    RaiseWindow(Tmp_win);
+	    KeepOnTop();
+	  }
+	  XSync(dpy,0);
+	  XAllowEvents(dpy,ReplayPointer,CurrentTime);
+	  XSync(dpy,0);
+	  return;
+    }
+#endif
+  
   XSync(dpy,0);
   XAllowEvents(dpy,ReplayPointer,CurrentTime);
   XSync(dpy,0);

-- 
Markus Gutschke            Internet: [email-masked]
Schlage 5a
D-48268 Greven-Gimbte
Germany

---

From: Markus Gutschke <[email-masked]>
Date: 05 Dec 1996 00:57:39 +0100

The patch that I posted with my last message still contained a minor
nuisance. It effectively turned "RaiseLower" into "Lower". Here comes
a bug-fixed version:

   BroadcastName(M_WINDOW_NAME,tmp_win->w,tmp_win->frame,
--- fvwm/events.c.orig	Mon May 27 21:33:26 1996
+++ fvwm/events.c	Thu Dec  5 00:53:22 1996
@@ -1030,6 +1030,26 @@
 
 	}
     }
+
+#ifndef SUPPRESS_CLICKTORAISE
+  else if ((Tmp_win) && !(Tmp_win->flags & ClickToFocus) &&
+	   Event.xbutton.window == Tmp_win->frame)
+    {
+      if (Tmp_win != Scr.LastWindowRaised &&
+	  (Event.xbutton.state &
+	   (ControlMask|Mod1Mask|Mod2Mask|Mod3Mask|Mod4Mask|Mod5Mask)) == 0 &&
+	  GetContext(Tmp_win,&Event, &PressedW) == C_WINDOW)
+	    {
+	      RaiseWindow(Tmp_win);
+	      KeepOnTop();
+	    }
+      XSync(dpy,0);
+      XAllowEvents(dpy,ReplayPointer,CurrentTime);
+      XSync(dpy,0);
+      return;
+    }
+#endif
+  
   XSync(dpy,0);
   XAllowEvents(dpy,ReplayPointer,CurrentTime);
   XSync(dpy,0);

---

From: "Randall S. Winchester" <[email-masked]>
Date: Thu, 5 Dec 1996 16:10:03 -0500 (EST)

Thank you, Markus, so very much! What a relief. Boy does it make raising
windows easier!

This has got to be up in the top two or three of my favorite patches to FVWM
in sometime.

Thanks again!
Randall

On 5 Dec 1996, Markus Gutschke wrote:

: The patch that I posted with my last message still contained a minor
: nuisance. It effectively turned "RaiseLower" into "Lower". Here comes
: a bug-fixed version:
: 
: --- fvwm/add_window.c.orig	Thu Apr 11 17:25:58 1996
: +++ fvwm/add_window.c	Wed Dec  4 23:41:13 1996
: @@ -492,8 +492,10 @@
:  			&a,&b,&JunkChild);
:    tmp_win->xdiff -= a;
:    tmp_win->ydiff -= b;
: +#ifdef SUPPRESS_CLICKTORAISE
:    if(tmp_win->flags & ClickToFocus)
:      {
: +#endif
:        /* need to grab all buttons for window that we are about to
:         * unhighlight */
:        for(i=0;i<3;i++)
: @@ -506,7 +508,9 @@
:  			ButtonPressMask, GrabModeSync,GrabModeAsync,None,
:  			Scr.FvwmCursors[SYS]);
:  	  }
: +#ifdef SUPPRESS_CLICKTORAISE
:      }
: +#endif
:    BroadcastConfig(M_ADD_WINDOW,tmp_win);
:  
:    BroadcastName(M_WINDOW_NAME,tmp_win->w,tmp_win->frame,
: --- fvwm/events.c.orig	Mon May 27 21:33:26 1996
: +++ fvwm/events.c	Thu Dec  5 00:53:22 1996
: @@ -1030,6 +1030,26 @@
:  
:  	}
:      }
: +
: +#ifndef SUPPRESS_CLICKTORAISE
: +  else if ((Tmp_win) && !(Tmp_win->flags & ClickToFocus) &&
: +	   Event.xbutton.window == Tmp_win->frame)
: +    {
: +      if (Tmp_win != Scr.LastWindowRaised &&
: +	  (Event.xbutton.state &
: +	   (ControlMask|Mod1Mask|Mod2Mask|Mod3Mask|Mod4Mask|Mod5Mask)) == 0 &&
: +	  GetContext(Tmp_win,&Event, &PressedW) == C_WINDOW)
: +	    {
: +	      RaiseWindow(Tmp_win);
: +	      KeepOnTop();
: +	    }
: +      XSync(dpy,0);
: +      XAllowEvents(dpy,ReplayPointer,CurrentTime);
: +      XSync(dpy,0);
: +      return;
: +    }
: +#endif
: +  
:    XSync(dpy,0);
:    XAllowEvents(dpy,ReplayPointer,CurrentTime);
:    XSync(dpy,0);
: 
: 
: -- 
: Markus Gutschke            Internet: [email-masked]
: Schlage 5a
: D-48268 Greven-Gimbte
: Germany
:

---

From: Elad Eyal <[email-masked]>
Date: Fri, 6 Dec 1996 17:20:53 +0200 (IST)

Good morning,

>  if(tmp_win->flags & ClickToFocus)

Thank you, Thank you, Thank you! I am dust to your feet and ketchup to
your burgers. Precisely what I wanted. Now I no longer have a desktop, but
_A_ desktop! Thank you veryveryvery much.

PS: How on Earth is one supposed to use the patch you sent? I applied the
changes manually, but what's the proper way to do it?

Thanks again, Markus,
 _

---

From: Markus Gutschke <[email-masked]>
Date: 07 Dec 1996 11:55:21 +0100

Hi,

Elad Eyal <[email-masked]> writes:
> your burgers.

I like that one ;-)

> Precisely what I wanted. Now I no longer have a desktop, but

You are welcome; I am glad that you like the patch.

> changes manually, but what's the proper way to do it?

I think, somebody else already answered this question, but then, it
might have been on one of the other mailing lists that I am subscribed
to.

If you have two (or more) files that differ only slightly, it is
usually better to send the changes only, rather than the entire
files. In order to make this process more automatic, there is a
powerful tool called "diff". It will calculate a list of the
differences and output a description of what needs to be changed in
order to get from the old version of the file, to the new
version. This is what is called a patch file. There are different
output options (c.f. "man diff"), but context-style or unified patches
are most human-readable and also offer a couple of other technical
benefits.

In order to automatically apply patches, you need to run the patch
file thru the tool "patch". The nice thing about this tool is, that it
ignores all additional information that it might find in the input
file. Thus you can directly pipe the news article into "pipe" without
having to strip the extra text lines.

You should probably have a look at the man pages for "patch" if you
never used it before; but I will give you a few hints. "patch" always
works relative to the current directory. This might not be exactly the
same as the one that was used for creating the patch files with
"diff".

For instance, the patch file might have been created in the directory
"/usr/src"; then all "fvwm" related filenames will be preceded with
"fvwm-2.0.43". On the other hand, you might have stored your source
tree in "/usr/tmp/my-fvwm", thus the prefix "fvwm-2.0.43" does not
work for you. In this case, you change into the directory
"/usr/tmp/my-fvwm" and then tell "patch" to strip off the first part
of the path. You do this by passing the option "-p1". Actually, it is
a very good idea, to always use this option even when it might not
appear to be neccessary, because it has yet another side effect that
spares you some trouble. So just make it a rule, to always pass this
option; in most cases it will probably have the form "-p0", which
tells "patch" not to strip any part of the patch.

There are two other options that I use frequently. "-l" tells "patch"
to ignore difference in "white-space" (that is, different amounts of
space or tab characters); "-s" tells "patch" to not echo the contents
of the input file to the screen.

After you ran "patch", the original files still exist. They will have
been renamed, so that the suffix ".orig" is attached to the name. This
allows you to revert to the original version, if the patch did not
work. If for some reason there have been problems, then you will find
files that end in ".rej". These files contain patches that could not
be applied.

Good luck and let me know, if you need further information,

Markus