Subject: Re: [PATCH] rebound after draging a window to edges

From: Jui-Hsuan Feng <[email-masked]>
Date: Sun, 20 Dec 1998 15:41:33 CST

Hi,

(The new Netscape replying function is broken on my Linux box, so I have to
use cut and paste to reply)
---------------------------------------------
On Fri, Dec 18, 1998 at 10:30:44PM -0600, Jui-Hsuan Feng wrote:
> Hi folks,
> 
> When driging a window to the right edge or bottom edge, it will rebound by
       ^^^^^^^
       Do you mean 'dragging' or 'bringing'?

       (that's dragging. Typo, my fault. Josh)

> 16 pixels, but not on the left or top edges. Here is the patch to
> change
> this behavior. Since I don't know the reason to keep them there, so I
> just
> commented out those lines. Think about this situation: drag a window
> such
> that the top part of the window is out of the display, then 'shade'
> it.
> It's gone! Except for restarting fvwm2, there seems no way to call it
> back.
> Hope some wizard can modify 'WindowList' feature to drag those out of
> display windows back (I haven't figure out how :( ).

Where is the problem about this? The bug you describe has nothing
to do with the bouncing, does it? And I don't see a way how you
could drag a window completely off the screen.

Bye

Dominik
-- 
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---------------------------------------------

The bouncing is 'fixed' in that patch. I brought about another issue
in my previous email (sorry about the confusion). To see how it goes,
suppose there is a menu in .fvwm2rc

AddToMenu Window-Ops  "Window Ops"  Title
+  "Move"         Move
+  "Resize"       Resize
+  "Raise"        Raise
+  "Lower"        Lower
+  "(Un)Shade"    WindowShade
+  "(De)Iconify"  Iconify
+  "(Un)Stick"    Stick
+  "(Un)Maximize" Maximize
+  ""             Nop
+  "Delete"       Delete
+  "Close"        Close
+  "Destroy"      Destroy
+  ""             Nop
+  "Refresh Win"  RefreshWindow

Then I drag an application windom by its border so that the title bar is out
of screen. Then use 'WindowShade' of the above menu to shade that application
window (I know that probably only insane people would do this), then it's
gone. I think it might be a good idea using 'WindowsList' (or not-preferable
WinList module) to drag thoes stray windows back to screen.

Regards
--
J. Joshua Feng                            (O)608/262-3640
Electrical & Computer Engr., Univ. of Wisconsin - Madison
http://www.cae.wisc.edu/~fengj  [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 21 Dec 1998 03:29:01 +0100

> suppose there is a menu in .fvwm2rc

Yes, I see that you 'fixed' that, but my question was why
you consider this a bug. I think that was done to prevent
exactly what you describe: losing a window off-screen.
So the window is bounced back a few pixels.

Bye

Dominik

---

From: Tim Phipps <[email-masked]>
Date: Mon, 21 Dec 1998 09:31:56 +0000

> So the window is bounced back a few pixels.

I think the issue may be the number of pixel that the window is brought
back.
16 seems like a large number, 1 may be better.  I can't remember if
there is a similar limit on moving windows off the left or top.

It is possible to try to move windows completely off screen: either type
Move +0 +1023 in an FvwmConsole and forget to put the p on the end of
the number to specify pixels and the window has gone 10 screens away! 
Sloppy/Click Focus windows can be moved with the mouse outside the
window frame which lets you put the window off screen.

It's not difficult to get windows back. You can change the default
WindowList function to move the window to 0 0, or if you know the name
you can use FvwmConsole or FvwmCommand or something similar to do a Next
[<name>] Move 0 0.

Cheers,
Tim.