Re: FVWM: window placement on deiconification

From: R Tapia <tapia_at_swcp.com>
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

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


On Wed, 10 May 2000, Dominik Vogt wrote:

> On Tue, May 09, 2000 at 11:19:26AM -0600, R Tapia wrote:
> > 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?
>
>
> 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, dominik_vogt_at_agilent.com
> --
> 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 majordomo_at_fvwm.org.
> To report problems, send mail to fvwm-owner_at_fvwm.org.
>

--
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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Wed May 10 2000 - 04:54:39 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:50 BST