[GRASS5] usability tweak on OSX

Hi,

Here's a window placement tweak that makes things a bit less annoying
on the Mac (and I guess elsewhere too) from the d.m zoom/pan buttons.

It's sort of bending to my preferences of where windows should be placed,
but we should specify something other than just dumping everything in
the middle of screen. Having to drag the windows to somewhere useful
everytime you start the program is a pain.

Index: d.m.tcl

RCS file: /home/grass/grassrepository/grass6/display/d.m/d.m.tcl,v
retrieving revision 1.41
diff -u -r1.41 d.m.tcl
--- d.m.tcl 1 Apr 2005 23:43:29 -0000 1.41
+++ d.m.tcl 7 Jun 2005 06:07:43 -0000
@@ -115,7 +115,7 @@
###############################################################################
proc term {cmd args} {
     global env
- eval exec -- xterm -e $env(GISBASE)/etc/grass-run.sh $cmd $args &
+ eval exec -- xterm -geometry -50-40 -e $env(GISBASE)/etc/grass-run.sh $cmd $args &
}

Idea: place the d.zoom instructions term near the bottom right corner.
Currently it seems to always end up right in the middle of the screen
over the top of the x0 monitor.

It would also be nice to place the grass shell window near the bottom-
left of the screen and the d.m GUI in the top right. I guess Lorenzo's
startup software launches the term & adding "-geometry +0-0" there might
take care of that one. As for placing the d.m GUI near the top right of
the screen, not really sure, but perhaps use the "place" command?

see the `man X` (7x) GEOMETRY section for more info on -geometry.

Tcl's "place" command:
  http://tcltk.free.fr/man/TkCmd/place.php3
  http://tcllib.sourceforge.net/BWman/BWidget.html#place

So.. do the GUI masters agree?

FWIW, on the Mac with the d.m GUI open I usually put the shell in the
bottom left, the x0 monitor in the top left, the GUI in the top right,
and "else" in the bottom right of the screen. On Linux I just use the
command line and my window manager remembers where I put things so this
isn't an issue for me there.

Also on the Mac I use the "X11 Focus Follows Mouse" patch that comes
with Gimp.App to stop the click-to-focus nightmare when running d.zoom
or d.where from the GUI. This only works when you start GRASS in X11
mode not OSX mode; I seem to recall someone once showing me where you
could change this in the Mac user settings, but I forget now. If it
can be found, it might be nice to add that to Lorenzo's tutorial! This
is what keeps me from using OSX mode. Also nice to mention what the
3-button mouse emulation keys are in the Mac tutorial too!

hmmm. d.m has shortcut keys. I didn't know that. v.digit could use these.

    bind . <$keycontrol-Key-o> {
        Dm::OpenFileBox {}
    }
    bind . <$keycontrol-Key-n> {
        Dm::new
    }
    bind . <$keycontrol-Key-s> {
        Dm::SaveFileBox {}
    }
    bind . <$keycontrol-Key-q> {
        DmPrint::clean; exit
    }
    bind . <$keycontrol-Key-x> {
        Dm::delete
    }
    bind . <$keycontrol-Key-w> {
        Dm::FileClose {}
    }
    bind . <$keycontrol-Key-p> {
    Dm::print

The NVIZ contol panel could also use some fixing in regard to window
placement. It tends to jump all over the place when you open/close e.g.
the lighting panel.

Hamish

Hamish,

I think this makes sense. Could you go ahead and apply the patch. I'm about
to leave for Spain and don't know if I'll get a chance to commit this from
my office computer or not.

While we're on the subject of windows, the settings window in v.digit is
really annoying. It always opens in a thin, vertical band that I then have
to stretch. Somewhere there has to be a window geometry setting for this,
but I can't find it so far. Any ideas?

Cheers,
Michael

On 6/7/05 12:40 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Hi,

Here's a window placement tweak that makes things a bit less annoying
on the Mac (and I guess elsewhere too) from the d.m zoom/pan buttons.

It's sort of bending to my preferences of where windows should be placed,
but we should specify something other than just dumping everything in
the middle of screen. Having to drag the windows to somewhere useful
everytime you start the program is a pain.

Index: d.m.tcl

RCS file: /home/grass/grassrepository/grass6/display/d.m/d.m.tcl,v
retrieving revision 1.41
diff -u -r1.41 d.m.tcl
--- d.m.tcl 1 Apr 2005 23:43:29 -0000 1.41
+++ d.m.tcl 7 Jun 2005 06:07:43 -0000
@@ -115,7 +115,7 @@

##############################################################################>
#

proc term {cmd args} {
     global env
- eval exec -- xterm -e $env(GISBASE)/etc/grass-run.sh $cmd $args &
+ eval exec -- xterm -geometry -50-40 -e $env(GISBASE)/etc/grass-run.sh
$cmd $args &
}

Idea: place the d.zoom instructions term near the bottom right corner.
Currently it seems to always end up right in the middle of the screen
over the top of the x0 monitor.

It would also be nice to place the grass shell window near the bottom-
left of the screen and the d.m GUI in the top right. I guess Lorenzo's
startup software launches the term & adding "-geometry +0-0" there might
take care of that one. As for placing the d.m GUI near the top right of
the screen, not really sure, but perhaps use the "place" command?

see the `man X` (7x) GEOMETRY section for more info on -geometry.

Tcl's "place" command:
  Tcl Tk
  http://tcllib.sourceforge.net/BWman/BWidget.html#place

So.. do the GUI masters agree?

FWIW, on the Mac with the d.m GUI open I usually put the shell in the
bottom left, the x0 monitor in the top left, the GUI in the top right,
and "else" in the bottom right of the screen. On Linux I just use the
command line and my window manager remembers where I put things so this
isn't an issue for me there.

Also on the Mac I use the "X11 Focus Follows Mouse" patch that comes
with Gimp.App to stop the click-to-focus nightmare when running d.zoom
or d.where from the GUI. This only works when you start GRASS in X11
mode not OSX mode; I seem to recall someone once showing me where you
could change this in the Mac user settings, but I forget now. If it
can be found, it might be nice to add that to Lorenzo's tutorial! This
is what keeps me from using OSX mode. Also nice to mention what the
3-button mouse emulation keys are in the Mac tutorial too!

hmmm. d.m has shortcut keys. I didn't know that. v.digit could use these.

    bind . <$keycontrol-Key-o> {
        Dm::OpenFileBox {}
    }
    bind . <$keycontrol-Key-n> {
        Dm::new
    }
    bind . <$keycontrol-Key-s> {
        Dm::SaveFileBox {}
    }
    bind . <$keycontrol-Key-q> {
        DmPrint::clean; exit
    }
    bind . <$keycontrol-Key-x> {
        Dm::delete
    }
    bind . <$keycontrol-Key-w> {
        Dm::FileClose {}
    }
    bind . <$keycontrol-Key-p> {
    Dm::print

The NVIZ contol panel could also use some fixing in regard to window
placement. It tends to jump all over the place when you open/close e.g.
the lighting panel.

Hamish

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

Hamish wrote:

Here's a window placement tweak that makes things a bit less annoying
on the Mac (and I guess elsewhere too) from the d.m zoom/pan buttons.

It's sort of bending to my preferences of where windows should be placed,
but we should specify something other than just dumping everything in
the middle of screen. Having to drag the windows to somewhere useful
everytime you start the program is a pain.

If placement isn't specified anywhere, then it's up to the window
manager as to where windows are placed. Most window managers allow the
user to configure this.

I have no idea how this applies to MacOSX (which I presume doesn't use
a WM).

- eval exec -- xterm -e $env(GISBASE)/etc/grass-run.sh $cmd $args &
+ eval exec -- xterm -geometry -50-40 -e $env(GISBASE)/etc/grass-run.sh $cmd $args &

We definitely shouldn't be hardcoding xterm placement inside d.m.

A better approach would be to set the xrdb name using -name, e.g.

  eval exec -- xterm -name xterm-grass ...

then place GRASS xterms using X resources, i.e.

  *xterm-grass.geometry: -50-40

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

> Here's a window placement tweak that makes things a bit less
> annoying on the Mac (and I guess elsewhere too) from the d.m
> zoom/pan buttons.
>
> It's sort of bending to my preferences of where windows should be
> placed, but we should specify something other than just dumping
> everything in the middle of screen. Having to drag the windows to
> somewhere useful everytime you start the program is a pain.

If placement isn't specified anywhere, then it's up to the window
manager as to where windows are placed. Most window managers allow the
user to configure this.

I have no idea how this applies to MacOSX (which I presume doesn't use
a WM).

FWIW, tweak was written for & on MacOSX. OSX places new windows as most
WMs do, ie near to the middle but skewed towards any free desktop real-
estate.

> - eval exec -- xterm -e $env(GISBASE)/etc/grass-run.sh $cmd $args &
> + eval exec -- xterm -geometry -50-40 -e $env(GISBASE)/etc/grass-run.sh $cmd $args &

We definitely shouldn't be hardcoding xterm placement inside d.m.

Why not? Will it break something or is it just bad practice to do so?
It's just hinting that it wants to be a little towards the center
of the screen from the bottom right corner, whatever that may be.
My linux WM (sawfish) will ignore X -geometry if I've given explicit
instructions for a certain window name to go somewhere.
?

A better approach would be to set the xrdb name using -name, e.g.

  eval exec -- xterm -name xterm-grass ...

Setting "-name xterm-grass" is a very good idea.

then place GRASS xterms using X resources, i.e.

  *xterm-grass.geometry: -50-40

No problem for me, but way too involved for avg Mac user. And avg Mac
user is the one using d.m and spawning windows all over the place,
not me. So why go to the trouble? Can't we just set good defaults &
let the advanced users override with their WM if they want to?

..hopefully spawning xterms is only a temporary work-around anyway..

Hamish

Hamish wrote:

> > - eval exec -- xterm -e $env(GISBASE)/etc/grass-run.sh $cmd $args &
> > + eval exec -- xterm -geometry -50-40 -e $env(GISBASE)/etc/grass-run.sh $cmd $args &
>
> We definitely shouldn't be hardcoding xterm placement inside d.m.

Why not? Will it break something or is it just bad practice to do so?

Bad practice. Specifying -geometry will override most of the
mechanisms by which the user can configure the placement.

It's just hinting that it wants to be a little towards the center
of the screen from the bottom right corner, whatever that may be.
My linux WM (sawfish) will ignore X -geometry if I've given explicit
instructions for a certain window name to go somewhere.

Other WMs may be the other way around, i.e. WM-based configurations
are used as a fallback if the application doesn't explicitly specify
placement.

> then place GRASS xterms using X resources, i.e.
>
> *xterm-grass.geometry: -50-40

No problem for me, but way too involved for avg Mac user. And avg Mac
user is the one using d.m and spawning windows all over the place,
not me. So why go to the trouble? Can't we just set good defaults &
let the advanced users override with their WM if they want to?

In general, per process settings (e.g. a -geometry switch) are
supposed to override any "global" settings (e.g. WM configuration
files).

While there may be WMs which have it backwards, we shouldn't be
assuming that is the case.

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

> > > + eval exec -- xterm -geometry -50-40 -e [...]

..

> > We definitely shouldn't be hardcoding xterm placement inside d.m.

..

Bad practice. Specifying -geometry will override most of the
mechanisms by which the user can configure the placement.

..

In general, per process settings (e.g. a -geometry switch) are
supposed to override any "global" settings (e.g. WM configuration
files).

Right. Command line params should always override defaults. Got it.

Is it possible for us to set xrdb/.Xresources settings on the fly?

e.g. we provide e.g. $GISBASE/etc/grass.Xresources and point xrdb to it
in Init.sh. Then (re)run xrdb on ~/.Xresources if it exists to let
folks maintain their own preferences. (Hopefully that overrides previous
settings of the same name?)

:confused:

Hamish

Hamish wrote:

> > > > + eval exec -- xterm -geometry -50-40 -e [...]
..
> > > We definitely shouldn't be hardcoding xterm placement inside d.m.
..
> Bad practice. Specifying -geometry will override most of the
> mechanisms by which the user can configure the placement.
..
> In general, per process settings (e.g. a -geometry switch) are
> supposed to override any "global" settings (e.g. WM configuration
> files).

Right. Command line params should always override defaults. Got it.

Is it possible for us to set xrdb/.Xresources settings on the fly?

e.g. we provide e.g. $GISBASE/etc/grass.Xresources and point xrdb to it
in Init.sh. Then (re)run xrdb on ~/.Xresources if it exists to let
folks maintain their own preferences. (Hopefully that overrides previous
settings of the same name?)

Running xrdb at all is usually a bad idea unless you are accessing
multiple hosts from a single X display and want the same resource
settings on all hosts. The reason is that Xt completely ignores
~/.Xdefaults if the RESOURCE_MANAGER property exists (i.e. if xrdb has
been run).

If "xrdb -query" generates any output, either you're making extensive
use of remote X clients, or your X startup was written by someone who
doesn't understand X. Unfortunately, the latter is quite common.

Window placement is meant to be a user choice. Just because some users
don't understand how to express that choice, it doesn't mean that we
should be deciding it.

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

On Thu, 2005-06-16 at 08:02, Glynn Clements wrote:

Window placement is meant to be a user choice. Just because some users
don't understand how to express that choice, it doesn't mean that we
should be deciding it.

I think you mean "honoring it", not "deciding it".

M

On Thu, 2005-06-16 at 08:02, Glynn Clements wrote:

Window placement is meant to be a user choice. Just because some users
don't understand how to express that choice, it doesn't mean that we
should be deciding it.

Umm...let me try that again. Glynn is right. What I meant to editorialize
was "Just because some users don't understand how to express that
choice, it doesn't mean that we shouldn't be honoring it." Two ways of
perhaps saying the same thing, alas.

M

I can understand and appreciate the philosophy behind this discussion. But
it still remains that the 'default' that Hamish proposed seems more
convenient than the existing 'default' for many of the increasing number of
GRASS users who may be sophisticated in GIS use, but know little of tweaking
x-windows parameters (and care less due to limited time and energy).

Is there some way that the lines proposed can check to see if a user has
decided to set up a custom window configuration? If so, it honors it; if
not, it goes with a configuration that spaces windows in a generally useful
placement (more useful than stacked on top of each other a bit left and
above center).

Whether we do nothing or define a set of windows placements, we are
determining where windows open on start up in the normal--unaltered--state.
That is, terms of the actual effect for the user, whatever we do determines
a window placement configuration. The main thing is to NOT override any
customization that a more sophisticated users might want to have.

Just my 2 centimos worth.

Michael

On 6/16/05 2:02 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Hamish wrote:

+ eval exec -- xterm -geometry -50-40 -e [...]

..

We definitely shouldn't be hardcoding xterm placement inside d.m.

..

Bad practice. Specifying -geometry will override most of the
mechanisms by which the user can configure the placement.

..

In general, per process settings (e.g. a -geometry switch) are
supposed to override any "global" settings (e.g. WM configuration
files).

Right. Command line params should always override defaults. Got it.

Is it possible for us to set xrdb/.Xresources settings on the fly?

e.g. we provide e.g. $GISBASE/etc/grass.Xresources and point xrdb to it
in Init.sh. Then (re)run xrdb on ~/.Xresources if it exists to let
folks maintain their own preferences. (Hopefully that overrides previous
settings of the same name?)

Running xrdb at all is usually a bad idea unless you are accessing
multiple hosts from a single X display and want the same resource
settings on all hosts. The reason is that Xt completely ignores
~/.Xdefaults if the RESOURCE_MANAGER property exists (i.e. if xrdb has
been run).

If "xrdb -query" generates any output, either you're making extensive
use of remote X clients, or your X startup was written by someone who
doesn't understand X. Unfortunately, the latter is quite common.

Window placement is meant to be a user choice. Just because some users
don't understand how to express that choice, it doesn't mean that we
should be deciding it.

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

Michael Barton wrote:

Is there some way that the lines proposed can check to see if a user has
decided to set up a custom window configuration?

No.

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