Subject: FVWM: window placement on deiconification

From: R Tapia <[email-masked]>
Date: Tue, 9 May 2000 11:19:26 -0600 (MDT)

This isn't a bug report, I'm just curious about the reason for a
particular aspect of FVWM's behavior.

Throughout 2.2 and in 2.3, the following happens:

	I move a window so that the top is not visible on the current page
	and then iconify it. When I deiconify it, the window appears
	with the top visible at the bottom of the current page.

I've always found this a bit disconserting. Whenever I install a new
version of fvwm2, I "fix" this behavior by commenting out a couple of
lines of code.  

At first, I thought that it was an obvious bug and that it would
eventually be fixed. As new versions came out, I assumed that that was the
behavior that the developers wanted.

I'm just wondering, is this a bug, a feature, or am I doing something
silly to make FVWM place deiconified windows as above? 

Cheers,

Ron

--
Outlook is conclusive proof that Microsoft's desktop monopoly
has harmed consumers.

--
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: Erik Steffl <[email-masked]>
Date: Tue, 09 May 2000 10:58:44 -0700

is this related to somewhat similar situation when I drag the window
across the borders of screen so that I get to the adjacent screen and
place it there, in some cases the window does not appear on the expected
side of screen but on the other side (e.g. I enetered the screen from
right, place window there and it's suddenly on the left side). this
happens only in few case, usually when I move the mouse back to previous
screen to quickly (could it be that the screen is correctly determined
but the mouse position is the new one in the screen I switched to
immediately after placing the window)?

	erik

---

From: Richard A Lee <[email-masked]>
Date: 09 May 2000 18:03:31 -0400

> silly to make FVWM place deiconified windows as above? 

I've been annoyed by that one, too.  I do hope the developers don't
consider it a feature.

---

From: Michael Han <[email-masked]>
Date: Tue, 09 May 2000 22:46:38 -0700

Previously from R Tapia
>	with the top visible at the bottom of the current page.

I can't reproduce this. Are you leaving anything out of your
description?

>version of fvwm2, I "fix" this behavior by commenting out a couple of

Care to share?

>silly to make FVWM place deiconified windows as above? 

Well, personally I'd say this is wrong, and doubt that anyone
disagrees. But I think this is the first time anyone's reported this.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"'Why is that toy on your head?' 'Because if I wear it anywhere else, it
chafes.'" - Chris Knight
--
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: Wed, 10 May 2000 09:03:47 +0200

> silly to make FVWM place deiconified windows as above? 

The reason:

  When you deiconify/unmaximize windows, fvwm will put them at the
  exact location where they were when they were iconified/maximized,
  *even if this was on a different page*.  But this is not what the
  user usually wants if the window or icon is currently on the screen.
  In this case the window is moved to the same screen position, but
  on the current page.  The problem is, that if a window was - say -
  at x=-10 on page (0 0) when it was iconified and you deiconify it on
  page (1000 0), does that mean it will have x=1000*screenwidth-10
  or x=1001*screenwidth-10?  That's why windows seem to jump from
  one end of the screen to the other.

I have taken great pains in the 2.3.x betas to prevent this.
Personally I couldn't find any 'window jumping' in a long time,
but if anybody sees something like this again I'm very grateful
for a bug report.  But - please check this against the latest
beta release (2.3.16 right now).  Otherwise you might report
problems that are already fixed.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-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: R Tapia <[email-masked]>
Date: Wed, 10 May 2000 03:54:30 -0600 (MDT)

Well, I did a vanilla install of fvwm-2.3.16 and made a very small
.fvwm2rc to demonstrate the problem, it's included below.

The first thing that I noticed was, well, I haven't been using icons for a
long time. That makes my subject header very misleading, sorry.

Iconify on an icon puts the window in the right place in 2.3.16,
yay! Sorry for stating otherwise.

The problem that I'm seeing is with the function that I use to retrieve
windows that I've iconified. I use a windowlist to retrieve iconified
windows and the function:

DestroyFunc WindowListFunc
AddToFunc WindowListFunc
+       I       WindowId $0 Iconify off
+       I       WindowId $0 MoveToPage
+       I       WindowId $0 Raise
 
So, if you use the .fvwm2rc below, move a window so that the upper left
hand corner is off the current page, iconify it, right click on the root
window, left click on "Bring Me", and left click on the entry
corresponding to the iconified window, then the window pops up in the
"wrong" place. Use alt-right-mouse-button on a window to move it around.

This could be a problem with the WindowListFunc that I'm using or it could
be a non-obvious case of "window jumping". I'm not sure.

I'd like a little reassurance that the WindowListFunc above is reasonable
and that FVWM is really putting the window in the wrong place before
submitting a bug report. 

Thanks for your comments,

Ron

Test .fvwm2rc:
====================================================
ModulePath /usr/local/libexec/fvwm/2.3.16

DeskTopSize 3x3
EdgeResistance 10000 0
EdgeScroll 100 100
ClickTime 150

AddToFunc InitFunction
+                       "I"     Module  FvwmPager 0 0

AddToFunc RestartFunction
+                       "I"     Module  FvwmPager 0 0

AddToFunc Move-or-Raise         "I" Raise
+                               "M" Move
+                               "D" Lower

DestroyFunc WindowListFunc

AddToFunc WindowListFunc
+       I       WindowId $0 Iconify off
+       I       WindowId $0 MoveToPage
+       I       WindowId $0 Raise

Mouse 3 R       N       Menu MyWindowList-Popup
Mouse 1 R       N       Menu RootMenu Nop

Mouse 1 W       M       Resize-or-Raise
Mouse 2 W       M       Iconify
Mouse 3 W       M       Move-or-Raise

Mouse 1 TS      A       Move-or-Raise
Mouse 2 TS      A       WindowShade
Mouse 3 TS      A       Move-or-Raise

Mouse 1 I       A       Iconify
Mouse 2 I       A       Iconify
Mouse 3 I       A       Move-or-Iconify

Key Left        A       C       Scroll -100 0
Key Right       A       C       Scroll +100 +0
Key Up          A       C       Scroll +0   -100
Key Down        A       C       Scroll +0   +100

AddToMenu MyWindowList-Popup "Window Lists"     Title
+ "Bring me      "   WindowList Alphabetic, NoSticky

AddToMenu RootMenu "Foo "       Title
+ "Restart FVWM2        "       Restart fvwm2

====================================================

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 May 2000 11:15:44 +0200

> and that FVWM is really putting the window in the wrong place before

Okay, understood.  There is a bug, but it's not in 'iconify'.
MoveToPage moves the window even if it already is on the current
page.  I can fix that.  This is still an issue if the original
window position is not on the current viewport.  I wanted to clean
this up anyway before 2.4 is released.  Thanks for the reminder :-)

Bye

Dominik ^_^

---

From: R Tapia <[email-masked]>
Date: Wed, 10 May 2000 04:21:04 -0600 (MDT)

> I can't reproduce this. Are you leaving anything out of your

Uh, a lot, really. I just sent another message to the list that explains
what I left out and how I was confused.

> >version of fvwm2, I "fix" this behavior by commenting out a couple of

In 2.2, I was commenting out:

    SetupFrame(t,new_x,new_y,
               t->frame_width,t->frame_height,False);
    t->Desk = Scr.CurrentDesk; */

inside the first 'if' in the function AutoPlace. That may have been
breaking something. I never noticed any breakage, but...

In 2.3.16, I had been commenting out some code in move_window_doit.
However, I just noticed tonight that it definitely was breaking some
window placement. Currently, I'm changing the following lines in
move_window_doit:

	    if(FinalX < 0)
	      FinalX += Scr.MyDisplayWidth;
    	    if(FinalY < 0)
      	      FinalY += Scr.MyDisplayHeight;

to:

	    if((FinalX + (int) width) < 0)
      	      FinalX += Scr.MyDisplayWidth;
	    if ((FinalY + (int) height) < 0)
              FinalY += Scr.MyDisplayHeight;

and I haven't noticed any breakage. I also don't know that that's anywhere
near the Right Thing(tm).

> disagrees. But I think this is the first time anyone's reported this.

Right, sorry about that. In the mail that I just sent, I described a way
to reproduce what I was seeing...not what I said I was seeing. 

Cheers,

Ron

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 May 2000 16:36:23 +0200

> and that FVWM is really putting the window in the wrong place before

Try it with the current development code. Your problem should go away in
most cases.

Bye

Dominik ^_^