Subject: Re: FVWM: Re: resizing windows (fwd)

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

> 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.

Oh, I forgot to say that in the second appproach, each time the pointer is
in the center during the recursion process the whole window shrinks to
the central rectangle. I hope this clarifies things a bit.

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: Lee Willis <[email-masked]>
Date: 16 Sep 1998 09:18:12 +0100

> the central rectangle. I hope this clarifies things a bit.

Well I have to say that I don't really like the dot approach that much,
I'd prefer that if the mouse really is in the _exact_ centre then we
just act as now ie leave the window the same size and the user would
have to go drag the sides ...   Oh and I would shrink each time with the
recursion idea or not in real-time anyway. I'd just wait till we'd find
out which direction we're shrinking in and then drag that side/corner
to the mouse ...

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

---

From: Tim Phipps <[email-masked]>
Date: Wed, 16 Sep 1998 10:22:04 +0100

> out which direction we're shrinking in and then drag that side/corner
Much nicer, please make it so I can turn it off though. Half the time I
start a resize it is to find out how big a window is so I can set some
Xdefaults for the next time it pops up. The current behaviour shows the
current size and then can be aborted with ESC.

I posted a patch to the workers list that allows the keypad numbers to
select menu items if the hot keys 1,2,3,4,5,6,7,8,9,0 are used.  This
lets me pop a menu with keypad_5 and then select a resize direction from
a keypad number which moves the mouse to the appropriate edge and then
starts a resize.  If you do the above change then resizing will start
right away at the current size i.e. shrinking won't involve enlarging
first and the resize will start at the current size.

As another whizzy enhancement would anybody be interested in a patch
that would make resize use the keypad number keys to move the pointer
(and therefore resize the window) in an intelligent way?  What I am
thinking is that e.g. keypad_9 would move the pointer up and right by
the resize increment specified by the window or 23 if none specified,
shift-keypad_7 would move up and left by 5 times the resize increment or
100 if none specified.

The numbers 23 and 100 seem to be what resize moves by when using the
arrow keys.

This would let you grow a term window by 5 columns by hitting keypad_5
(or alt-keypad_5 if you want to be able to type numbers in using the
keypad) then keypad_6 to start a resize_right_edge then keypad_6 five
more times to add the columns ad then return to actually do the resize. 
I might even allow keypad_enter to work like return (actually this would
be useful in menus too.

All we need now is OpaqueResizeSize.

Cheers,
Tim.

---

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

> Well I have to say that I don't really like the dot approach that much,

Well, I just thought I'd conform to some concepts one meets in calculus.

> have to go drag the sides ...

Again, it's up to you.

   Oh and I would shrink each time with the
> out which direction we're shrinking in and then drag that side/corner

Yes, I think seeing the window shrink many times would look ugly.

I was just trying to illustrate the concept.

Best wishes,

Neil