Subject: FVWM: "Window Creep"

From: Michael Alan Dorman <[email-masked]>
Date: Mon, 22 Apr 1996 15:16:05 -0400

I've just started using fvwm2.  I'm using version 2.0.42 (as packaged
by Austin Donnely for Debian Linux).

I've found a very odd bit of behavior, best described as "Window
Creep".  In short, as I open copies of Mosaic over the source of a
session, their starting positions move progressively further to the
right.

I've got the following styles in my .fvwmrc2.

Style	"*"		Icon unknown.xpm
Style	"*"		BorderWidth 0
Style	"*"		HandleWidth 0
Style	"*"		MWMFunctions
Style	"*"		HintOverride
Style	"*"		Color White/DarkGreen
Style	"*"		NoPPosition
Style	"*"		SmartPlacement
Style	"*"		SloppyFocus
Style	"*"		IconBox -50 -100 -1 -1
Style	"FvwmButtons"	NoTitle, Sticky, WindowListSkip, ClickToFocus

I would guess this would be an issue with SmartPlacement (it also
seems to act differently than in fvwm 1.X, in that it's not so careful
about making sure windows are up against the top left corner of the
available space).

Any ideas?

Mike.
--
"Don't let me make you unhappy by failing to be contrary enough...."
--
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: Austin Donnelly <[email-masked]>
Date: Mon, 22 Apr 96 20:38 BST

> Style	"FvwmButtons"	NoTitle, Sticky, WindowListSkip, ClickToFocus

This is because SmartPlacement doesn't entail ActivePlacement (as it
used to). So, if there is no room for the new window, it is placed
anywhere. RandomPlacement isn't really that random, but picks
somewhere semi-sane: this is the window creep you're seeing.

The fix is to say:

Style "*"		SmartPlacement, ActivePlacement

Hope this helps,
Austin

---

From: "Jeff S. Elam" <[email-masked]>
Date: Mon, 22 Apr 1996 12:46:24 -0700

> about making sure windows are up against the top left corner of the

I've had similar problems with a database application that I use:  Clarify.
However, Clarify is the only app that has this problem, so I always figured
it was a Clarify problem, except that Clarify is the only app that I bring up
without a specific geometry statement, so it's hard to say.

Clarify stores the location of its windows in the database when you exit, and
uses that information to know where to bring up the windows next time.
However, I guess it makes incorrect assumptions about the border width or
something like that, because the window is always about 6 pixels higher than
where it appeared in the last invocation.

Maybe Mosaic is doing something similar.  Then again, maybe this didn't help
at all.  :-)

-- 
-Jeff E.
[email-masked]

---

From: tim werner <[email-masked]>
Date: Tue, 23 Apr 1996 08:03:55 -0400

>Date: Mon, 22 Apr 96 20:38 BST
>From: Austin Donnelly <[email-masked]>

>Style "*"		SmartPlacement, ActivePlacement

Why would you want to have the WM pick a place for the window and then
have it force you to move it around with the mouse and then click before
you can start typing?  Just curious.

tw

---

From: Austin Donnelly <[email-masked]>
Date: Tue, 23 Apr 96 13:29 BST

> you can start typing?  Just curious.

SmartPlacement means that if there is room on-screen for the window,
then it will be placed there automatically.

DumbPlacement won't bother looking for space on screen.

ActivePlacement and RandomPlacement specify the policy to be used if
SmartPlacement/DumbPlacement fail.

Austin

---

From: Peter Funk <[email-masked]>
Date: Tue, 23 Apr 1996 13:11:27 +0200 (MESZ)

Jeff S. Elam wrote:
[...about windows changing their location from run to run...]
je> I've had similar problems with a database application that I
je> use:  Clarify.  [...]
 
je> Clarify stores the location of its windows in the database when
je> you exit, and uses that information to know where to bring up the
je> windows next time.  However, I guess it makes incorrect assumptions
je> about the border width or something like that, because the window
je> is always about 6 pixels higher than where it appeared in the
je> last invocation.

je> Maybe Mosaic is doing something similar.  Then again, maybe this
je> didn't help at all.  :-)

Indeed this seems to be a problem in fvwm (at least in 1.24r).

I've some applications, which store the window locations from previous
invocations in the same manner.  Whenever such an application program
creates a window using the x,y-coordinates remembered from the previous
run, the new window is moved right and down about the framewidth
resp. framewidth + titlebar height.  This does not happen with mwm,
SGIs 4Dwm or Solaris ol(v)wms.

fvwm seems to use the x,y-coordinates delivered to XCreateWindow for
upper left corner of the frame window and not the pane window as 
other window managers happen to do.  So the pane window get's 
increased x,y coordinates for each new run of the application.

I've looked into fvwm-1.24r/fvwm/placement.c and this behaviour seems to be
intended by the author.  There is the following comment line near the
end of the function 'PlaceWindow':
	/* put it where asked, mod title bar */

Any idea, how to keep this applications from drifting further into 
the south east corner of the screen each time they are invoked ?
Editing 'placement.c' was my first idea, but that has the serious
disadavantage of having to edit all -geometry options in .fvwmrc,
.xinitrc and the like, whenever the framewidth or title bar height
is going to be changed.
 
Regards, Peter
-=-=-
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany
office: +49 421 2041925 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
--
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: Albrecht Kadlec <[email-masked]>
Date: 26 Apr 1996 17:59:57 +0200

> 	/* put it where asked, mod title bar */

well one would want a window with -geom +0+0 to be placed at 0/0
(border edge!!!)
That means that the application pane has to be at
Borderwidth/Titleheight. If that is stored, that's a problem.

I always had the maybe related problem with 1.24, that my emacs is placed
slightly off-screen :
I had to specify    (left . -7) (top . 23)  as the geometry values for
emacs to get it in the top right corner.

I'm glad this was corrected in 2.xx (can't remember, but it's gone now.)
(identify says the geometry is +551-90, grrrrr)

anayway there's also that odd bug that -0-0 isn't done right 
(i.e: first converted to integer, so the "-" is lost resulting in 0/0
placement).

maybe these two could be taken care of together ?

regards,
albrecht