Matt Doggett wrote:
> It seems to be a bug in certain window managers; dtwm and BlackBox
> have both been reported as having problems, fvwm and twm both work.
How could it be a bug in the window manager? I could resize monitors
just fine in 4.3 but not in 5.0. GRASS changed...my wm did not.
4.3 doesn't include the code which triggers the bug, 5.0 does.
If there's a bug in any functionality which is part of the system
(rather than in an application), only programs which actually use that
functionality will have problems. That doesn't mean that the bug is in
those programs.
> XDRIVER itself adds geometry constraints when a client connects, and
> removes them when the client finishes. This was added to prevent users
> from resizing the monitor in the middle of an interactive program
> (e.g. v.digit, d.what.*), as the programs can't handle this.
So are you telling me that Grass5.0 is programmed to lock the monitor
window so that a user cannot resize it once it is open and selected? If
so, this is a fundamentally different way of handling monitor windows
than Grass4.3.
No. GRASS 5.0 inhibits resizing while a program is running. Resizing
should be allowed once the client terminates; however, certain WMs
fail to notice when the restriction is removed.
> The problem is that certain window managers honour the geometry
> constraints even after they have been removed. You can confirm this
> using the "xprop" utility.
I've used the xprop utility and get the following results. The main
thing is that Grass5.0 is calling the XDRIVER and specifying tighter
constraints for the monitor (e.g. not specifying max/min sizes).
Not specifying a min/max size means that there are no constraints upon
resizing. E.g. xlogo doesn't specify a min/max size, and can be
resized arbitrarily. xterm specifies a minimum but no maximum, and so
can be resized to any size above the minimum. Many programs don't
specify a min/max size.
If
this is normal, fine, then I can deal with it. The main thing is that
I'm just used to the Grass4.3 functionality which lets you resize your
monitor window while it's open and selected. If Grass5.0 is programmed
not to let the user do it, then so be it.
See above.
GRASS4.3 (notice that it specifies a min and max size...allowing
resizable monitors):
No. If there are no min/max size, you can (notwithstanding WM bugs)
resize the window arbitrarily.
To inhibit resizing, XDRIVER sets both the min/max sizes to the
current window size. Use xprop while a client (e.g. d.what.rast) is
connected to see this in action:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified size: 640 by 480
program specified minimum size: 640 by 480
program specified maximum size: 640 by 480
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 10, 10
user specified size: 450 by 400
program specified minimum size: 0 by 0
program specified maximum size: 1260 by 994
Note that the 1260x994 is fiction. XDRIVER is simply guessing what the
min/max size ought to be, based upon the screen size. The "correct"
solution is not to specify any limits.
GRASS5.0 (notice the fixed size. The WM is doing exactly what GRASS5.0
is telling it to do?):
The problem was that you could resize the window while a client was
running. This confused people, as the client won't acknowledge the
change; it reads the size at startup and assumes that it remains
constant.
So, it was requested to prevent resizing while a client was running.
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified size: 640 by 480
> Also, if you start the monitor without selecting it:
>
> d.mon -s start=x0
>
> you should be able to resize it.
Note: if you use xprop at this point, you will get the "typical"
setting for WM_NORMAL_HINTS. Yet, at this point, you *can* resize it.
So, the problem is that, once a min/max size has been set, certain WMs
remember the min/max size; you can change the limits, but any attempt
to remove them is ignored.
--
Glynn Clements <glynn.clements@virgin.net>