Subject: FVWM: Re: resizing windows

From: Neil Zanella <[email-masked]>
Date: Wed, 9 Sep 1998 19:04:54 -0230 (NDT)

To resize a window you must start a "Resize" operation.
How this is done will depend on the system configuration file or on
your own personal .fvwmrc / .fvwm2rc file if you have one (the latter
would usually be found in your home directory).
The most popular ways of starting a "Resize" operation are by clicking on
a button of the title bar of the window you wish to resize and holding the
mouse button down and/or choosing "Resize" or the like from a Popup menu
and then clicking on the desired window and holding the mouse button down.
Once you start a resize operation the following things will happen:
a) you can shrink (or widen) a window horizontally by first moving the pointer
   to a vertical side bar
b) you can shrink (or widen) a window vertically by first moving the pointer
   to a horizontal side bar
c) to shrink (or expand) a window in both directions just move the pointer
   to the frame (in this context the word "frame" stands for the corners).

... as you can see, there should be no need to enlarge a window before
shrinking it.

I hope this helped,

Neil

--
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: Michael Hucka <[email-masked]>
Date: Thu, 10 Sep 1998 16:58:55 GMT

Thank you (and others) for your replies.  I appreciate the fact that you were
trying to help, but I see now that I wrote my question in such a way to make
it seem like I was a clueless newbie.

Let me try to restate the question.  I know about resize handles.  It is true
that if you resize using the resize handles, you can shrink a window without
having to grow it first.  I failed to explain that I normally use resize from
a mouse binding.  I do this very simply, using the following in my .fvwm2rc:

    Mouse 2 WFSTI	MS  Resize

This allows me to start a resize operation with the cursor anywhere on a
window, by pressing meta-shift-button-2.  (I find modifier key + button
combinations much faster to use than having to first seek out the appropriate
window frame/border element.  It's a big win for operations like iconifying
and pushing/popping windows.)

What I find annoying is that after I press meta-shift-button-2 on a window, I
cannot resize it until I slide the cursor to the edge of the window and
actually make the window *larger*.  Then I can strink it.  I wish it were
possible to avoid that, and start the resize operation right away, without
first moving to the window edges.

Another list reader (Chris Siebenmann) understood what I meant in my original
question, and said that this is probably a hardcoded feature of fvwm.  If so,
then I guess there is no configuration option that would change the behavior,
and it would require modifying the C code (which I wouldn't mind trying, if I
only had the time....).

-- 
Mike Hucka  ---  [email-masked]  ---  http://ai.eecs.umich.edu/people/hucka

---

From: Tim Phipps <[email-masked]>
Date: Fri, 11 Sep 1998 09:19:22 +0100

> first moving to the window edges.

You would have to patch the code to do this.  You would also have to
come up with some way to let fvwm know which edges you want to move i.e.
there are eight different resize directions so you would need eight new
commands or a new command with fancy args.

There is something you can do that might help, it won't do exactly what
you want but it might make it bearable.  If you bind Alt-keypad-5 to pop
up a menu you can have the menu give all eight choices hot-keyed from
numbers.  Each menu choice would call a function that warps the mouse to
the appropriate edge or corner and then call resize.  You would still
have to grow the window to get the resizing to start but at least the
mouse would be in the desired part of the window.  The numbers for hot
keys will give you an intuitive key sequence where you hit alt-keypad-5
(in the middle of the pad) then the number key in the direction you want
to resize.  Let me exemplify:

Key KP_5 WTSF M resize_menu #WTSF means anywhere but root or icon

AddToMenu resize_menu "Pick a resize direction" Title
+ "&7 Up Left" resize_dir 0 0
+ "&8 Up" resize_dir 50 0
+ "&9 Up Right" resize_dir 100 0
+ "&6 Right" resize_dir 100 50
+ "&3 Down Right" resize_dir 100 100
+ "&2 Down" resize_dir 50 100
+ "&1 Down Left" resize_dir 0 100
+ "&4 Left" resize_dir 0 50

AddToFunc resize_dir "I" WarpToWindow $0 $1
+                    "I" Resize

Let me know if you think this is useful.

Cheers,
Tim.

---

From: Michael Tiefenback <[email-masked]>
Date: Fri, 11 Sep 1998 09:55:17 -0400 (EDT)

I have been following the discussion started by Hucka about window
resizing features, and it makes me recall a module written by Elad Eyal,
<[email-masked]> a year or so ago.  My last update on it was Aug 1997.
It is a module with which you bodily take the named window and put it
where you want it and resize it as you go.  Click of the mouse gives one
corner, release gives the other corner.  I gave the author marginal help
ni testing his module, and flagged some issues with other color depths
than he was using.  It seemed very usable, but my normal window habits
are not very conducive to using FvwmGeom.  If the files are not available
from the author, I could tar up the source again and send it to interested
parties.

I don't think FvwmGeom is part of the regular distribution.  If it is,
please ignore me gracefully.

Michael Tiefenback

---

From: Richard Lister <[email-masked]>
Date: Fri, 11 Sep 1998 10:05:41 -0400

On Thu, 10 Sep 1998 16:58:55 GMT
Michael Hucka <[email-masked]> 
> first moving to the window edges.

What's really happening is that you are moving the cursor to go and grab
the rubber band used for resizing. This behaviour dates all the way back
to twm.

I for one can't think of an alternative scheme to the rubber band for
indicating arbitrary resize operations. Anyone got good ideas?

Ric

Richard J Lister, Georgetown Institute for Cognitive and Computational Sciences
Georgetown University Medical Center, Washington, DC 20007, USA
Phone: +1 202-687 2878
Email: [email-masked] 
Web: http://www.giccs.georgetown.edu/~ric/
--
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: Neil Zanella <[email-masked]>
Date: Fri, 11 Sep 1998 15:08:24 -0230 (NDT)

> indicating arbitrary resize operations. Anyone got good ideas?

Yes, we could resize windows dynamically like in AfterStep.
In any case I don't see why you should move outward to grab the rubber
band.
Why can't the window automatically turn to a rubber band and shrink toward
the pointer when you start a resize operation?

Neil

---

From: Lee Willis <[email-masked]>
Date: 14 Sep 1998 10:04:28 +0100

> the pointer when you start a resize operation?

But which border should shrink toward the cursor?   That's the most
difficult part to acheive otherwise I would argue that it's a nice
feature to have but unless you define eight different key presses/mouse
actions/buttons how does the WM decide which way you want to resize?

Lee.
-- 
Lee Willis
GBDirect Ltd, 27 Park Drive, Heaton, Bradford, UK, BD9 4DS
Tel: +44 (0)1274 772277

---

From: Neil Zanella <[email-masked]>
Date: Mon, 14 Sep 1998 11:53:31 -0230 (NDT)

On 14 Sep 1998, Lee Willis wrote:

> But which border should shrink toward the cursor?

The closest one to the cursor.

Hence you could have:

Mouse 1 A SC MoveSideResize
Mouse 2 A SC MoveFrameResize

There must be some way for the program to determine the shortest distance
from the mouse to the side (S) or corners (F). Of course, if the poiter
is equidistant from 2 sides/corners then a choice will have to be
performed. That's up to you.performed. That's up to you.

   That's the most
> actions/buttons how does the WM decide which way you want to resize?

Can't the WM figure out the 4 distances from the pointer to the 4
borders/corners and determine the shortest one?

Neil

---

From: [email-masked] (Carl R. Witty)
Date: 14 Sep 1998 15:45:53 -0700

> The closest one to the cursor.

I'm pretty sure I've used a window manager (I don't remember which
one) which would divide the window into 9 equal rectangles:

	1 2 3
	4 5 6
	7 8 9

If you started a resize while the mouse was in region 1, 3, 7, or 9,
it would resize that corner.  If you started a resize while the mouse
was in region 2, 4, 6, or 8, it would resize that size.  I don't
remember what would happen if you started a resize from region 5.

Carl Witty
[email-masked]

---

From: Neil Zanella <[email-masked]>
Date: Mon, 14 Sep 1998 21:18:58 -0230 (NDT)

> remember what would happen if you started a resize from region 5.

Now I see where you're coming from.
Here is an alternative to the problem. Divide a window like this:

Join the points 1,*,2,*,3,*,4,*,5,*,6,*,8,*    in that order.

(see diagram below)

with straight lines. The hard part is computing the positions of the

points. To do that first draw a circle centered at *, then divide the

circle in 8, then draw a box around the circle, and shrink the box so that

the vertical side is original_side * height / widh . This defines a

compression of the contnets of the box and hence the points on the circle.

Then draw the lines *----1', *-----2', ... *----9' where 1', 2', ..., 8'

were those points on the circle. These lines intersect the frame at points

1, 2, 3, 4, 5, 6, 7, 8

This gives you the reqired points 1,2,3,4,5,6,7,8 . Now you only have to

worry about the behavior at point *. Chose whichever you prefer, eg. one

corner goes to the center.

<------------------- width ----------->

+----------1--------------2-----------+     ^
|                                     |     |
|                                     |     |
|                                     |     |
8                                     3
|                                     |
|                  *                  |
|                                     |    height
7                                     |
|                                     4
|                                     |     |
|                                     |     |
|                                     |     |
+----------6--------------5-----------+     ^

Best regards and wishes,

Neil

---

From: [email-masked] (Carl R. Witty)
Date: 14 Sep 1998 18:56:17 -0700

> Here is an alternative to the problem. Divide a window like this:
[ ... into 8 octants. ]

One advantage of the scheme I described is that once you've started
the resize, the window manager puts up the move/resize rubber-bands.
In fvwm (and in the window manager I'm remembering), these divided the
window into 9 rectangles; this would give you feedback as to whether
you selected the region you thought you selected.

Also, in terms of predictability, I think it may be easier for people
to figure out where the regions are with my scheme.

Carl Witty
[email-masked]

---

From: Neil Zanella <[email-masked]>
Date: Tue, 15 Sep 1998 14:13:38 -0230 (NDT)

> to figure out where the regions are with my scheme.

That's true. With my scheme things get tough when you move the pointer
toward the ceneter. I was just inspired by pthe "Pie WM" for a moment.

Would it be possible if when you clicked on 5 then for the whole window
to shrink to a dot? Then you can pull it out in whatever direction you
wish.

Alternatively (and perhaps this is a bit more complex), take the GNU
approach: recursion. The middle window is divided into 9 just like
the big window. If when you do that your pointer is still in the center
then apply this idea recursively. Unless the pointer was in the very
center of the window then this recursion must end. If the pointer just
happens to be right in the middle then shrink everything to a dot like in
what I suggest above.

Best wishes,

Neil

---

From: Lee Willis <[email-masked]>
Date: 16 Sep 1998 09:15:35 +0100

Neil Zanella <[email-masked]> writes:

> approach: recursion.

Damn you mean they've GPL'd recursion now :)

Lee.

---

From: Chris Siebenmann <[email-masked]>
Date: Wed, 16 Sep 1998 19:15:27 -0500

| Why can't the window automatically turn to a rubber band and shrink
| toward the pointer when you start a resize operation?

 This would make it very hard to back out of a resize without changing
the window's size.

	- cks

---

From: Neil Zanella <[email-masked]>
Date: Wed, 16 Sep 1998 23:14:36 -0230 (NDT)

> Damn you mean they've GPL'd recursion now :)

I take it you're joking :-) . I was referring to the recursive acronym

standing for "GNU's NOT UNIX". Of course there's only one iteration

otherwise it becomes:

((((GNU's not Unix)'s not Unix)'s not Unix)'s not Unix)...

which makes little sense.

Neil