Subject: FVWM: ResizeMove query

From: Andy Arbon <[email-masked]>
Date: Wed, 20 Mar 2002 20:51:01 +0000

Hello,

I have the function below, which I use for 'maximising' a window onto my 
first monitor (for complicated reasons, I can't use the Maximise 
functions properly), but for some reason the window always appears a 
little too tall, so that the bottom of the window just disappears off 
the screen a little.

Adjusting the size parameters subtly doesn't seem to fix this!

DestroyFunc Max-Pri-Mon
AddToFunc Max-Pri-Mon		"I"	ResizeMove 1152p 864p 0p 0p
+ 
			"I"	Raise

Does anyone have any suggestions what could be wrong?
The function is bound to Alt-F10, not that I think that makes any 
difference.

The function below is nearly OK.. the only problem is that the window 
doesn't quite reach the bottom of the screen. With this function, I'm 
more curious why the numbers have to be seemingly weird to make it fit? 
On a 1152x864 monitor I thought the numbers would be 1152p 864p?

DestroyFunc Max-Pri-Mon
AddToFunc Max-Pri-Mon		"I"	ResizeMove 1149p 841p 0p 0p
+ 

Thanks,

Andy

--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 20 Mar 2002 23:57:43 +0100

> AddToFunc Max-Pri-Mon		"I"	ResizeMove 1149p 841p 0p 0p

First, applications usually specify a size increment.  Their
windows can only be resized by a multiple of that size.  This is
usually the font width and height.  Therefore, you won't be able
to fill the screen exactly for many applications.

The reason why the above ResizeMove command makes the window too
large is that the "Resize" variants round up to a multiple of the
step size while most other commands round down.  Let me think if
that should be considered as a bug.

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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 20 Mar 2002 23:29:08 +0000

On 20 Mar 2002 20:51:01 +0000, Andy Arbon wrote:
> +				"I"	Raise

There are 2 issues here.

First you can't fit some windows exactly. For example xterms.
Try to maximize xterm or, say, FvwmPager. Chances are that you get gaps.
This is how xterm says it should be resized.

The second issue is that Resize gets the size of a client window not
the window frame. So if you have border with width 3 and title with width
18, frame will be 6 pixels wider by X and 24 pixels higher.

So try another method instead:

  DestroyFunc Max-Pri-Mon
  AddToFunc Max-Pri-Mon
  + I Move 0p 0p
  + I Resize bottomright 1152p 864p
  + I Raise

Currently Move and Resize can't be combined here, but Dominik will surely
fix this. :)

But, as I said xterm or other terminal emulator, may not fix exactly.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 20 Mar 2002 23:34:46 +0000

> that should be considered as a bug.

No, Resize round down not up, as needed. :)

Current Resize 300p 300p
Current FvwmIdent

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 21 Mar 2002 00:50:30 +0100

> Currently Move and Resize can't be combined here, but Dominik will surely

Hey, ever thought of fixing something yourself? ;-)

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 21 Mar 2002 00:51:35 +0100

> No, Resize round down not up, as needed. :)

And ResizeMove does the same:

  Current Resize 300p 300p $[w.x]p $[w.y]p

results in the same geometry.  I wonder what's going wrong here.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 21 Mar 2002 01:07:44 +0100

> No, Resize round down not up, as needed. :)

The resize arguments add the border dimensions to the final
geometry.  It's very easy to fix, but that probably breaks some
old setups relying on it(?).  Should we make that change?  Any if
yes, should be fix it in the 2.4 branch too?

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 21 Mar 2002 01:50:30 +0000

> yes, should be fix it in the 2.4 branch too?

I think Resize works correctly. I don't think it should be changed.

Currently it resizes the client window, this is usually what is important.
Also, the size of the client is what is shown in the mini-info window.
Both lines are currently equivalent for many applications:

  Resize 300p 300p
  Resize 300c 300c

The only case when the size of the frame not the client window should be
considered is when trying to fit the frame into a rectangle (page), in
this case the size of the client window is not important by intention.
It probably may be done using a new prefix, like 300pf 300pf.

It would be good if Maximize and Resize were consistent from the start on
'p' syntax, but their main intention is different, the first mainly works
on the whole frame, the secont on the client window. Probably Maximize may
support 'c' prefix.

Anyway, there should be a way to resize a window regardless of the
decoration size.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 21 Mar 2002 10:57:06 +0100

> Anyway, there should be a way to resize a window regardless of the

  Resize Frame 100 100

?

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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 [email-masked].
To report problems, send mail to [email-masked].