Subject: Notification: incoming/623

From: [email-masked]
Date: Tue, 30 May 2000 01:22:25 -0500 (CDT)

FVWM Bug Tracking notification

new message incoming/623

Message summary for PR#623
	From: [email-masked]
	Subject: resizing maximized windows
	Date: Tue, 30 May 2000 01:13:52 -0500
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 31 May 2000 02:45:54 +0200

On Tue, May 30, 2000 at 01:22:25AM -0500, [email-masked] wrote:
> it seems to me, like some change in fvwm during the last months
> caused, that clients can no longer resize their windows when
> these are maximized.

... [reason: fvwm ignores resize requests from maximized windows]

I think it *might* be necessary that we 'fix' that before
2.4 to keep backwards compatibility.  A style option could
control this:

  Style * ResizeMaximized Program

or

  Style * ResizeMaximized off

In the first case a program is allowed to resize its maximized
windows, in the second it isn't.  The code for this is fairly
simple.  Apart from all the stuff that has to bew done for new
styles, a few lines in HandleConfigureNotify() have to be
changed plus a similar patch for size_inc changes.

Should we do this or not?  I have not made up my mind yet.
The patch should be small enough - so it isn't a big issue,
but if I continue writing more and more new features it
might take a long time before 2.4 is ready.

--

The reason for the peculiar syntax is that I have a future
enhancement in mind:

  Style * ResizeMaximized User

or

  Style * ResizeMaximized User Program

This would allow the user to resize a maximized window
without resetting the 'maximized' state.  The use model
I have in mind is this:

  1) You have a normal terminal window and want to see
     more lines, but don't want to maximize it - either
     because the window would become too big or because
     to maximize it vertically you would have to press
     one or more modifier keys.
  2) Instead you grab the window border and start resizing,
     but with e.g. button 2 or a modifier pressed.  This would
     immediately set the maximized flag (we'll need something
     like 'maximize on keep keep' too) and then start resizing.
  3) You can simply unmaximize the window to restore the old
     geometry.

Personally I run into this problem very often.  Fvwm is not
as comfortable as it could be.  The patches to implement this
are probably non-trivial.  The whole resizing code assumes
it's resizing the frame.  So this is definitely a post-2.4
enhancement.

> Actually, the only client where I encounter this problem is gimp.
> Gimp has a function named "shrink-wrap" that tries to resize the
> window to the current image size. With recent versions of fvwm,
> this doesn't work anymore, when the window is maximized. Gimp
> obviously thinks, that the resize succeeded and redraws the image
> in the upper left corner with the scrollbars around it, but the
> window just stays maximized and doesn't change its size.
> 
> I am not sure, which fvwm-version introduced this behavior
> change, I only can tell that it was between fvwm 2.2.2 and
> 2.3.11. Is it a bug or just a new feature, that I don't
> understand? Is there any way, to get the old behavior back?
> 
> To reproduce:
> 1) start gimp (1.1.x)
> 2) load some image
> 3) push the maximize button on the image window's titlebar
>    (or whatever else you have bound to fvwm's maximize function)
> 4) in the image window's context menu, call "View/Shrink wrap"

[note: this happens only if the window does not move in the
same operation, i.e. if the top left corner stays in place]

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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]