Subject: Re: FVWM: EdgeResistance and Focus

From: Robert Tarrall <[email-masked]>
Date: Tue, 19 Mar 1996 13:21:06 -0700

Kai Grossjohann wrote:
->   - When the mouse pointer is warped to a window (with Focus, say), it
->     is warped to the upper left hand corner.  Is there a way to have
->     it warpt to the center instead?

Seconded!

->   - Fvwm doesn't understand "-0" in the X-offset or Y-offset fields of
->     a geometry specification.

Works for me, e.g. "xev -geometry -0+0" starts a window in the upper right
corner of the screen, in v 2.0.41 under IRIX.  Is this what you meant?

			-Robert Tarrall.-
			Unix System/Network Admin
			Laboratory for Computational Dynamics
			CU - Boulder
--
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: Mike Blatchley <[email-masked]>
Date: Tue, 19 Mar 1996 20:36:01 -0700 (MST)

> corner of the screen, in v 2.0.41 under IRIX.  Is this what you meant?

I am running fvwm 2.0.40 and 2.0.41 under Solaris 2.3.  I can specify "-0"
when exec'ing a program, as Robert showed above, and the window is
positioned just fine.  But, I know of 1 little "geometry" problem with the
IconBox style: 

  Style "*" IconBox 5 -80 -140 -1

positions the icon box along the bottom of the screen (bottom edge of box 
is 1 pixel above bottom edge), but

  Style "*" IconBox 5 -80 -140 -0
                               ^^
doesn't.  Icons show up just anywhere on the screen.  So, in this 
instance, fvwm does not like a '-0'.  I thought I had sent this to Chuck 
Hines a while back, but I must have spaced it out since it's not 
anywhere in my mail log.  Sorry.

Is it something like this that you're seeing?

Mike Blatchley
[email-masked]

---

From: Kai Grossjohann <[email-masked]>
Date: 20 Mar 1996 09:31:20 +0100

>>>>> On Tue, 19 Mar 1996 20:36:01 -0700 (MST), Mike Blatchley
>>>>> <[email-masked]> said:

  Mike>   Style "*" IconBox 5 -80 -140 -0
  Mike>                                ^^
  Mike> doesn't.

This is what I meant.  It turns out that FvwmPager and FvwmIconMan and
FvwmWinList all understand "-0", so this is not much of a problem for
me.  I don't use IconBox anyway...

Thanks a lot for your answer,
        kai
--
~/.signature

---

From: [email-masked] (Barton E. Schaefer)
Date: Fri, 22 Mar 1996 17:07:35 -0800

I've yet to come up with a compelling reason to switch from 1.x, so I
thought I'd lob the question to this list.  I'm not subscribed yet, so
please copy me on replies, but I have perused the FAQ and list archive
from <URL:http://www.hpc.uh.edu/fvwm>.

I find that I'm using nearly every one of the fvwm 1.x settings that
have been dropped in 2.0:

   Cursor  cursor_num cursor_type             (obsoleted)
   OpaqueResize                               (obsoleted)
   StickyBackColor colorname                  (obsoleted)
   StickyForeColor colorname                  (obsoleted)
   StubbornIcons                              (obsoleted)
   StubbornIconPlacement                      (obsoleted)
   StubbornPlacement                          (obsoleted)

Of these, Cursor and StubbornIcons are the most important (even though
StubbornIcons seems to work only part of the time).  OpaqueResize is
also extremely useful for debugging window geometry problems in other
applications (especially Motif), because you can watch the confusion
develop as the window shape changes.

One other setting that I don't currently use, but that I've played with
in the past, is DontMoveOff.  The FAQ says there's no equivalent; what
is the closest similar effect?  (I'm surprised that there's no mention
of this anywhere in the list archives ... maybe people who are used to
virtual desktops just aren't bothered by windows that don't stay on the
screen, but I'd prefer to have it available just so that it's possible
to duplicate MWM very closely.  Fvwm as "the window manger that can be
any other window manager" is an attractive concept.)

I'm also using these functions:

   CirculateDown [ name window_name ]         Next (not compatible)
   CirculateUp [ name window_name ]           Prev (not compatible)
   Warp [ name window_name ]                  Next or Prev (not compatible)

I could probably live without these if somebody can suggest how to get
the closest possible behavior out of Next and Prev, but I haven't found
any explanation in the mailing list archives for why they were dropped.
(Again, the real ones would be nice to have for MWM-cloning.)

I'm also using TogglePage, and I hope it'll make it back in before
there is an official release.  I haven't seen this mentioned in the
list archives, so I'll throw in the comment that TogglePage really
needs the PagingDefault setting to work properly; so don't forget to
put that (or the equivalent) back as well.

Finally, so that this message can be at least a bit constructive, I've
attached diffs for fvwmrc_convert (from 2.0.41) to fix a few cases it
mishandled (primarily Cursor and OpaqueResize). 

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
[email-masked]                  Division of NCD Software Corporation
http://www.well.com/www/barts
--- ../utils/fvwmrc_convert	Thu Oct  5 11:34:18 1995
+++ /space/tmp/fvwmrc_convert	Fri Mar 22 15:03:43 1996
@@ -25,8 +25,8 @@
 # 24 May 95
 
 echo "fvwmrc-to-2 1.7a"
-if [ ! -x /usr/local/contrib/bin/gnu/gawk ];then
-   echo "gawk (/usr/local/contrib/bin/gnu/gawk) missing, cannot run"
+if ! gawk --version 2>/dev/null ;then
+   echo "gawk (Gnu Awk) not found, cannot run"
    exit 1
 fi
 source=${1:-$HOME/.fvwmrc}
@@ -80,7 +80,7 @@
 
 /TogglePage/ {
 		print "#! " $0 " (TogglePage not in fvwm2)";
-		print "Warning: TogglePage function not in fvwm2, use EdgeScroll"\
+		print "Warning: TogglePage not yet implemented in fvwm2, use EdgeScroll"\
 			>"/dev/stderr";
 		next;
 		}
@@ -246,7 +246,7 @@
 	}
 /^StdBackColor[	 ]/ {
 	    dflt["stdbackcolor"]=stdbackcolor=$2;
-	    printf ("#!%s (new command=Style \"*\" Color f/b)\n)\n", $0);
+	    printf ("#!%s (new command=Style \"*\" Color f/b)\n", $0);
 	    print "Style \"*\" BackColor " $2;
 	    next;
 	}
@@ -257,7 +257,7 @@
 /^MWMFunctionHints$/ { printf ("Style \"*\" MWMFunctions\n"); next; }
 /^MWMDecor$/         { printf ("Style \"*\" MWMDecor\n"); next; }
 /^MWMDecorHints$/         { printf ("Style \"*\" MWMDecor\n"); next; }
-/^MWMBorder$/        { printf ("Style \"*\" MWMBorder\n"); next; }
+/^MWMBorders$/       { printf ("Style \"*\" MWMBorder\n"); next; }
 /^MWMButtons$/       { printf ("Style \"*\" MWMButtons\n"); next; }
 /^MWMHintOverride$/  { printf ("Style \"*\" HintOverride\n"); next; }
 /^RandomPlacement$/ { print "Style \"*\" " $0; next; }
@@ -269,7 +269,7 @@
 /^SuppressIcons$/      { print "Style \"*\" NoIcon"; next; }
 /^StickyIcons$/      { print "Style \"*\" StickyIcon"; next; }
 
-/^AutoRaise[	 ]/	{ print "#! " $0 " (use Module FvwmAuto)";
+/^AutoRaise[	 ]/	{ print "#!" $0 " (use Module FvwmAuto)";
 			  print "AddToFunc \"InitFunction\" \"I\" Module FvwmAuto " $2;
 			  next;
 			}
@@ -292,7 +292,7 @@
 /^WindowFont[	 ]/    { print $0; next; }
 /^IconFont[	 ]/      { print $0; next; }
 /^Stubborn/ {
-	print "#! " $0;
+	print "#!" $0;
 	print "Warning: " $1 " not in Fvwm2, command dropped">"/dev/stderr";
 	next;
  }
@@ -302,19 +302,28 @@
 /^EdgeResistance[	 ]/ { print $0; next; }
 /^DeskTopSize[	 ]/ { print $0; next; }
 /^DeskTopScale/ {
-	print "#! " $0;
+	print "#!" $0;
 	print "Warning: " $1 " not in Fvwm2, command dropped">"/dev/stderr";
 	next;
  }
-/^WindowListSkip[	 ]/ { print "#! $0 [deleted]";
+/^OpaqueResize/ { print "#!" $0 " [not yet implemented]";
+		if (warned[$1]==FALSE)
+		{
+		print "Warning: " $1 " commented out, not yet implemented" >"/dev/stderr";
+		warned[$1] = TRUE;
+		}
+		next;
+	}
+/^Cursor[	 ]/ { print "#!" $0 " [not yet implemented]";
 		if (warned[$1]==FALSE)
 		{
-		print "Warning: " $1 " commented out, obsolete" >"/dev/stderr";
+		print "Warning: " $1 " commented out, not yet implemented" >"/dev/stderr";
 		warned[$1] = TRUE;
 		}
 		next;
 	}
-/^Pager/ { print "#! $0 [deleted]";
+/^WindowListSkip[	 ]/ { print "Style " $2, $1; next; }
+/^Pager/ { print "#!" $0 " [deleted]";
 		if (warned[$1]==FALSE)
 		{
 		print "Warning: " $1 " commented out, obsolete (use FvwmPager)" >"/dev/stderr";
@@ -324,7 +333,7 @@
 	}
 
 /^PagingDefault[ 	]/ { 
-	print "#! " $0 " (use EdgeScroll 0 0)"; next;
+	print "#!" $0 " (use EdgeScroll 0 0)"; next;
 	print "Warning: PagingDefault not in Fvwm2, use EdgeScroll 0 0">"/dev/stderr";
  }

---

From: Kai Grossjohann <[email-masked]>
Date: 25 Mar 1996 09:06:29 +0100

>>>>> On Fri, 22 Mar 1996 17:07:35 -0800, [email-masked]
>>>>> (Barton E. Schaefer) said:

  Barton> One other setting that I don't currently use, but that I've
  Barton> played with in the past, is DontMoveOff.  The FAQ says
  Barton> there's no equivalent; what is the closest similar effect?

There is EdgeResistance where you can set a number of pixels.  The
window won't be moved off-screen unless you move it off-screen by more
than that number of pixels.

  Barton> I could probably live without these if somebody can suggest
  Barton> how to get the closest possible behavior out of Next and
  Barton> Prev, but I haven't found any explanation in the mailing
  Barton> list archives for why they were dropped.

IMVHO, Next and Prev are the greatest thing under the sun.  While
they're not compatible to CirculateUp and CirculateDown, they do what
I have always wished Circulate{Up,Down} to do:  With Circulate, the
movement is in a window ring where the relative positions of the
windows are based on the time of creation of the windows.  (This may
be completely wrong as my idea of what the Circulate functions do is
based on twm not fvwm...)

With Next/Prev the relative position of the windows is based on the
order of `visiting' them, i.e. with Prev I can go to the last window I
was in before the current one.

        kai
--
There ain't no cure for the summer time blues.

---

From: [email-masked] (Barton E. Schaefer)
Date: Mon, 25 Mar 1996 02:09:21 -0800

On Mar 25,  9:06am, Kai Grossjohann wrote:
} Subject: Re: FVWM: Why use fvwm 2.0?
}
}   Barton> played with in the past, is DontMoveOff.  The FAQ says
}   Barton> there's no equivalent; what is the closest similar effect?
} 
} There is EdgeResistance where you can set a number of pixels.  The
} window won't be moved off-screen unless you move it off-screen by more
} than that number of pixels.

OK, I should have thought of that myself.  But will EdgeResistance
prevent initial placement from being offscreen?  What's the fvwm 2
equivalent of mwm's PositionOnScreen?

} IMVHO, Next and Prev are the greatest thing under the sun.  While
} they're not compatible to CirculateUp and CirculateDown, they do what
} I have always wished Circulate{Up,Down} to do:  With Circulate, the
} movement is in a window ring where the relative positions of the
} windows are based on the time of creation of the windows.  (This may
} be completely wrong as my idea of what the Circulate functions do is
} based on twm not fvwm...)

Hmm.  I'd never really paid close attention, but my impression of
Circulate{Up,Down} is that there is no fixed ring, but a cycle
determined entirely by the stacking order at the instant the
function is used.  E.g. CirculateDown takes the topmost window and
pushes it to the bottom, and CirculateUp takes the bottom-most
window and pulls it to the top.

In the virtual-mwm I've used (IXI Panorama) the definitions of
"topmost" and "bottom-most" get a bit confused, because *all* the
windows have a stacking order as if they were on a single desktop,
so you can end up circulating windows you can't see; but it still
works by instantaneous stacking order as far as I can tell.

Maybe it's different if you use click-to-focus rather than focus-
follows-pointer; when I use circulate, it's always from a root menu
or a root-window key binding, so the cursor is in the root and no
window has focus.

That reminds me of a related question:

When using focus-follows-pointer, Focus (e.g. from FvwmWinList)
warps the pointer to the upper left corner of the window frame.
Is there some way to get it to put the cursor actually inside the 
window, rather than on the frame?

---

From: Kai Grossjohann <[email-masked]>
Date: 25 Mar 1996 11:38:19 +0100

>>>>> On Mon, 25 Mar 1996 02:09:21 -0800, [email-masked]

  Bart> But will EdgeResistance prevent initial placement from being
  Bart> offscreen?  What's the fvwm 2 equivalent of mwm's
  Bart> PositionOnScreen?

Hm.  Well...  Initial placement offscreen?  I don't think there's
anything in fvwm that prevents this, but I've never had any problems
with windows being created (partially or fully) offscreen.  I think I
misunderstood you -- sorry.

  Bart> E.g. CirculateDown takes the topmost window and pushes it to
  Bart> the bottom, and CirculateUp takes the bottom-most window and
  Bart> pulls it to the top.

Woa, I made another mistake here.  I was thinking of a different
function entirely.  So forget what I said.

  Bart> When using focus-follows-pointer, Focus (e.g. from
  Bart> FvwmWinList) warps the pointer to the upper left corner of the
  Bart> window frame.  Is there some way to get it to put the cursor
  Bart> actually inside the window, rather than on the frame?

I use a function instead:

AddToFunc GoThere               "I" Iconify -1
+                               "I" Focus
+                               "I" CursorMove 3 3

Instead of using the Focus action, you just call this function.  Btw,
"CursorMove 3 3" means move 3% of the screen right and 3% down.

        kai

---

From: [email-masked] (Barton E. Schaefer)
Date: Mon, 25 Mar 1996 12:59:21 -0800

On Mar 25, 11:38am, Kai Grossjohann wrote:
}
}   Bart> When using focus-follows-pointer, Focus (e.g. from
}   Bart> FvwmWinList) warps the pointer to the upper left corner of the
}   Bart> window frame.  Is there some way to get it to put the cursor
}   Bart> actually inside the window, rather than on the frame?
} 
} I use a function instead:
} 
} AddToFunc GoThere               "I" Iconify -1
} +                               "I" Focus
} +                               "I" CursorMove 3 3

I haven't tried this with 2.0 yet, but in 1.24r the CursorMove happens
only if the (un)Iconify does *not* happen.

*FvwmWinListAction Click1 Iconify -1,Focus,CursorMove +3 +3

---

From: [email-masked] (Barton E. Schaefer)
Date: Mon, 25 Mar 1996 09:41:49 -0800

On Mar 25, 11:38am, Kai Grossjohann wrote:
} Subject: Re: FVWM: Why use fvwm 2.0?
}
}   Bart> What's the fvwm 2 equivalent of mwm's
}   Bart> PositionOnScreen?
} 
} Hm.  Well...  Initial placement offscreen?  I don't think there's
} anything in fvwm that prevents this, but I've never had any problems
} with windows being created (partially or fully) offscreen.

It happens most often with multi-window apps, when you drag one of the
windows to another part of the virtual desktop and then the window gets
closed for some reason while it's off-screen.  Re-opening that same
window then places it at the same relative geometry, i.e. offscreen
again.  This can be very confusing.

---

From: Ching-Han Tsai <[email-masked]>
Date: Mon, 25 Mar 1996 15:22:10 -0600 (CST)

> *FvwmWinListAction Click1 Iconify -1,Focus,CursorMove +3 +3

Actually in version 1.24 it's pretty easy to warp the pointer to the 
middle of the window, instead of the upper left corner. In v1.24 all you 
need to do is to locate the following line in functions.c:

    XWarpPointer(dpy, None, Scr.Root, 0, 0, 0, 0, x+2, y+2);
                                                  ^^^^^^^^
and change it to:

    XWarpPointer(dpy, None, Scr.Root, 0, 0, 0, 0, 
                 x+t->frame_width/2, y+t->frame_height/2); 
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I just checked the source code of v2.0.41. The same piece of code is now
in builtins.c, but since it looks exactly the same as the corresponding
part in functions.c of v1.24, I guess the above modification would work
in 2.0 too.

Ching-Han