[GRASS5] Monitor Resize Problem
Bob Covill
bcovill at tekmap.ns.ca
Wed Jul 18 22:06:20 EDT 2001
Glynn Clements wrote:
>
> Bob Covill wrote:
>
> > > > The window manager I am using on the Sun is the dtwm, part of the
> > > > Solaris install. I do not know the version number off hand, but it is
> > > > the one packaged with Solaris 7, if that helps.
> > > >
> > > > Below is the output from xprops on the monitor ....
> > > >
> > > > WM_STATE(WM_STATE):
> > > > window state: Normal
> > > > icon window: 0x3404224
> > > > _DT_WORKSPACE_PRESENCE(_DT_WORKSPACE_PRESENCE) = 0x101
> > > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW
> > > > WM_CLASS(STRING) = "x0", "GRASS 5.0.0pre1"
> > > > WM_HINTS(WM_HINTS):
> > > > bitmap id # to use for icon: 0x6800002
> > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > program specified size: 450 by 400
> > >
> > > This suggests that the WM ought to allow the window to be resized.
> > > When resize is (intentionally) inhibited, xprop should show:
> > >
> > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > program specified size: 450 by 400
> > > program specified minimum size: 450 by 400
> > > program specified maximum size: 450 by 400
> > >
> > > Can you try modifying src/display/devices/XDRIVER/XDRIVER24/Client.c,
> > > line 22. Currently, it should read:
> > >
> > > szhints->flags = PSize;
> > >
> > > Settings worth trying include
> > >
> > > szhints->flags = PPosition | PSize;
> >
> > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > program specified location: 0, 0
> > program specified size: 450 by 400
> >
> > > and
> > > szhints->flags = USPosition | USSize;
> >
> > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > user specified location: 0, 0
> > user specified size: 450 by 400
> >
> > > and
> > > szhints->flags = 0;
> >
> > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> >
> > >
> > > Let me know which of these (if any) work.
> > >
> > > --
> > > Glynn Clements <glynn.clements at virgin.net>
> >
> > Glynn,
> >
> > I tried the above changes to Client.c. I have appended the output from
> > xprop to each change, if that helps. Note that there were no HINTS for
> > flag = 0.
> >
> > I was not able to resize the monitor after the abovce changes with the
> > exception of "flags = 0". In the case of "flags = 0" I was able to
> > resize the monitor until I drew in it. After that I was unable to resize
> > it. The size seems to be getting locked somehow?? Could it be leaving a
> > lock (??) file somewhere?
>
> There's no file involved; the only way in which the min/max size could
> become permanent is if the WM records the min/max size but then
> ignores their subsequent removal. In which case, the only solution
> would be to never specify a min/max size.
>
> This appears to be a WM bug. I'd expect that with KDE, but not dtwm.
> However, I would also expect such a bug to break most X programs.
>
> One further check to perform: disable set_size() completely (i.e.
> delete/comment/"#if 0" the entire body). This should result in the old
> behaviour.
>
> > For the above changes, I only did "gmake5 -i" in the XDRIVER24
> > directory. Does anything else have to be rebuilt to pick up the changes?
>
> No. And the xprop output indicates that the changes *are* being picked
> up.
>
> --
> Glynn Clements <glynn.clements at virgin.net>
> _______________________________________________
> grass5 mailing list
> grass5 at geog.uni-hannover.de
> http://www.geog.uni-hannover.de/mailman/listinfo/grass5
Glynn,
Disabling set_size() seems to have worked. Below is the output from
xprop.
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x3404901
_DT_WORKSPACE_PRESENCE(_DT_WORKSPACE_PRESENCE) = 0x101
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW
WM_CLASS(STRING) = "x0", "GRASS 5.0.0pre1"
WM_HINTS(WM_HINTS):
bitmap id # to use for icon: 0x6400002
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 10, 10
user specified size: 450 by 400
WM_CLIENT_MACHINE(STRING) = "tekmap"
WM_COMMAND(STRING) = { "x0" }
WM_ICON_NAME(STRING) = "GRASS 5.0.0pre1 - Monitor: x0"
WM_NAME(STRING) = "GRASS 5.0.0pre1 - Monitor: x0"
I guess the question is now, is the problem unique to my particular
setup or will other Solaris dtwm machines have the same problem?
Let me know if I can provide any more info or testing.
Thanks for your help.
--
Bob Covill
Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada
E-Mail: bcovill at tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498
More information about the grass-dev
mailing list