[GRASS5] monitor resize

Hi,

I have a question. I remember I was able to resize the XDRIVER monitor
by dragging the edge of the window with mouse. But now I cannot, maybe
from 6.0 (?). Is this intended (then why?) or a window manager problem?
I know there is d.resize, but it's sometimes inconvenient.

Thank you.
Huidae Cho

Huidae Cho wrote:

I have a question. I remember I was able to resize the XDRIVER monitor
by dragging the edge of the window with mouse. But now I cannot, maybe
from 6.0 (?). Is this intended (then why?) or a window manager problem?
I know there is d.resize, but it's sometimes inconvenient.

You cannot resize the window while a client is connected. The
dimensions which the driver reports to the client must remain correct
for the lifetime of the client.

However, there have been reported problems with some window managers
refusing to allow resizing even when no client is connected. The most
likely reason is that they are recording the min/max size which are
set while a client is connected then continuing to enforce the
restrictions after they are removed.

One thing to try is to change:

  szhints->flags = PSize;
to:
  szhints->flags = 0;

on line 24 of display/drivers/XDRIVER/XDRIVER24/Client.c, and/or
changing:

    szhints->flags = USSize;
to:
    szhints->flags = 0;

on line 205 of display/drivers/XDRIVER/XDRIVER24/Graph_Set.c.

Let me know how this works out; the existing code works OK with all of
the window managers which I have tried.

--
Glynn Clements <glynn@gclements.plus.com>

> I have a question. I remember I was able to resize the XDRIVER
> monitor by dragging the edge of the window with mouse. But now I
> cannot, maybe from 6.0 (?). Is this intended (then why?) or a
> window manager problem? I know there is d.resize, but it's sometimes
> inconvenient.

You cannot resize the window while a client is connected. The
dimensions which the driver reports to the client must remain correct
for the lifetime of the client.

However, there have been reported problems with some window managers
refusing to allow resizing even when no client is connected. The most
likely reason is that they are recording the min/max size which are
set while a client is connected then continuing to enforce the
restrictions after they are removed.

One thing to try is to change:

  szhints->flags = PSize;
to:
  szhints->flags = 0;

on line 24 of display/drivers/XDRIVER/XDRIVER24/Client.c, and/or
changing:

    szhints->flags = USSize;
to:
    szhints->flags = 0;

on line 205 of display/drivers/XDRIVER/XDRIVER24/Graph_Set.c.

Let me know how this works out; the existing code works OK with all of
the window managers which I have tried.

Using the Fluxbox WM (~1 year old version) on Debian:

The resizing control (and window border) are there when you first create
the window with d.mon, but disappear as soon as you call anything (eg
d.erase). `d.mon stop=xN && d.mon start=xN` doesn't always bring them
back unless you start/stop a different number monitor first.

The above two code changes don't have any affect, AFAICT.

Are there any verbose xwininfo options that may be of help for checking
the window's state?

Hamish

On Sat, Oct 01, 2005 at 01:31:28PM +1200, Hamish wrote:

> > I have a question. I remember I was able to resize the XDRIVER
> > monitor by dragging the edge of the window with mouse. But now I
> > cannot, maybe from 6.0 (?). Is this intended (then why?) or a
> > window manager problem? I know there is d.resize, but it's sometimes
> > inconvenient.
>
> You cannot resize the window while a client is connected. The
> dimensions which the driver reports to the client must remain correct
> for the lifetime of the client.
>
> However, there have been reported problems with some window managers
> refusing to allow resizing even when no client is connected. The most
> likely reason is that they are recording the min/max size which are
> set while a client is connected then continuing to enforce the
> restrictions after they are removed.
>
> One thing to try is to change:
>
> szhints->flags = PSize;
> to:
> szhints->flags = 0;
>
> on line 24 of display/drivers/XDRIVER/XDRIVER24/Client.c, and/or
> changing:
>
> szhints->flags = USSize;
> to:
> szhints->flags = 0;
>
> on line 205 of display/drivers/XDRIVER/XDRIVER24/Graph_Set.c.
>
> Let me know how this works out; the existing code works OK with all of
> the window managers which I have tried.

Using the Fluxbox WM (~1 year old version) on Debian:

The resizing control (and window border) are there when you first create
the window with d.mon, but disappear as soon as you call anything (eg
d.erase). `d.mon stop=xN && d.mon start=xN` doesn't always bring them
back unless you start/stop a different number monitor first.

The exact same things happened to me. I'm working around this problem with a
dirty script:

---
#!/bin/sh
start=0
if echo $@ | grep 'sta.*=' > /dev/null 2>&1
then
  start=1
  mon=`echo $@ | sed 's/^.*=//'`
elif ! echo $@ | grep '=' > /dev/null 2>&1
then
  if ! echo $@ | grep 'help' > /dev/null 2>&1
  then
    start=1
    mon=$@
  fi
fi

if [ $start -eq 1 ]
then
  d.mon -s $mon
  sleep 1
  d.mon select=$mon
else
  d.mon $@
fi
---

This script is aliased to d.mon.

The above two code changes don't have any affect, AFAICT.

Are there any verbose xwininfo options that may be of help for checking
the window's state?

I have no idea about this.

Huidae Cho

Hamish wrote:

> Let me know how this works out; the existing code works OK with all of
> the window managers which I have tried.

Using the Fluxbox WM (~1 year old version) on Debian:

The resizing control (and window border) are there when you first create
the window with d.mon, but disappear as soon as you call anything (eg
d.erase). `d.mon stop=xN && d.mon start=xN` doesn't always bring them
back unless you start/stop a different number monitor first.

The above two code changes don't have any affect, AFAICT.

Are there any verbose xwininfo options that may be of help for checking
the window's state?

xprop will list the properties associated with a window. The
WM_NORMAL_HINTS property is the one which normally controls resizing.

--
Glynn Clements <glynn@gclements.plus.com>

> > Let me know how this works out; the existing code works OK with
> > all of the window managers which I have tried.
>
>
> Using the Fluxbox WM (~1 year old version) on Debian:
>
>
> The resizing control (and window border) are there when you first
> create the window with d.mon, but disappear as soon as you call
> anything (eg d.erase). `d.mon stop=xN && d.mon start=xN` doesn't
> always bring them back unless you start/stop a different number
> monitor first.
>
> The above two code changes don't have any affect, AFAICT.
>
> Are there any verbose xwininfo options that may be of help for
> checking the window's state?

xprop will list the properties associated with a window. The
WM_NORMAL_HINTS property is the one which normally controls resizing.

First off, I'd mention that 'd.mon sel=x0' does as good a job of losing
the frame (and resizing ability) as d.erase or any other display
command. So to keep things simple I've used that to trigger it.

Working case (GNOME + Sawfish WM + Debian's XFree86 4.3):

`xprop`:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified size: 585 by 720

`xprop -spy` as `d.mon sel=x0` is executed:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified size: 585 by 720
                program specified minimum size: 585 by 720
                program specified maximum size: 585 by 720
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified size: 585 by 720

Failing case (Fluxbox WM + XFree86 4.2.1):

`xprop`:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
[nothing, next item]

`xprop -spy` as `d.mon sel=x0` is executed:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified minimum size: 640 by 480
                program specified maximum size: 640 by 480
WM_NORMAL_HINTS(WM_SIZE_HINTS):

No diff between before and after states as shown by xwininfo and xprop
when `d.mon sel=x0` is run triggering presence/absence of frame.

Hamish