This patch adds tests to the cross platform wm.test
file while removing them from unixWm.test. These
tests would have made it easier to catch bug
571600, for example.
This patch does make one change, in the sense
that something that did not raise an error in
the past will raise an error in 8.4.
A geom command like:
wm geom . +1+-10
Is not valid. The implementation of ParseGeometry
would incorrectly parse this y coord as a negative
number even though the y coord sign (saved in
the wmPtr->flags as WM_NEGATIVE_Y) would not
be set.
There were other variations like "+1--10" that
would not raise an error while parsing but would
not act correctly either. The docs for the geom
command state that only a single - or + character
can come before a x or y value.
Patch to fixup wm geom and add test cases
Logged In: YES
user_id=72656
In what way is +1+-10 invalid? It seems to do the expected
thing (10 pixels about the top border), although I'm not sure
what that is worth.
Logged In: YES
user_id=90858
Here is what the current docs have to say about it:
wm geometry window ?newGeometry?
If newGeometry is specified, then the geometry of
window is changed and an empty string is returned.
Otherwise the current geometry for window is
returned (this is the most recent geometry speci-
fied either by manual resizing or in a wm geometry
command). NewGeometry has the form =widthx-
height+-x+-y, where any of =, widthxheight, or
+-x+-y may be omitted. Width and height are
positive integers specifying the desired dimensions
of window.
The older docs read "xy" (I don't know how that will
show up on your machine, but on mine it looks like a plus
above a minus). At any rate, the point is that the
x and y values should be positive. If you want to declare
a negative y value it means start from the bottom of the
screen (as in "-10-10"). The code in ParseGeometry was
parsing off the initial + or - and then sending the
rest to strtoul on unix and strtol on Win and Mac.
That is not correct. Only a single + or - char should
be allowed. The old code let junk like "+1--2" through.
That contridicts the docs and I can't figure what
it would be good for.
Logged In: YES
user_id=79902
With experience, [wm geom . +1+-10] is necessary for those
(hopefully rare) times when a window needs to be placed off
one of the edges. The problem comes when you have some code
to center a window, and the window is wider (or taller) than
the screen; the obvious way of doing it (see below) fails.
set x [expr {([winfo screenwidth .]-[winfo width .])/2}]
# Ditto for y...
wm geometry . [format {+%d+%d} $x $y]
I've had applications that failed on laptops (embarrasingly,
in front of a demo to my boss) because Tk threw an error,
and I don't want to go through *that* loop again.