[GRASS-dev] question about icons in GRASS 7

GRASS GRASS developer
1

A question has come up about the future home of icons in GRASS 7.

Long ago, there were few icons and they lived in $GISBASE/bwidget and $GISBASE/etc/tcltkgrass.

As we came to have a full-fledged GUI, we had a great icon move several years ago that put them into $GISBASE/etc/gui/icons

Somewhere along the way, with an improvement in GRASS docs and the addition of graphic elements to doc pages, a set of icons is now recreated in $GISBASE/docs/html/icons

With wxPython, we have been experimenting with alternative icon sets (a 'silk' set in addition to the 'classic' GRASS set), and a new set is in development. At first, the silk icons were put into $GISBASE/icons/silk. But this year, these were moved to $GISBASE/docs/html/icons/silk.

Currently, in trunk, the legacy TclTk interface and the wxPython interface in 'classic' mode, uses GRASS icons in $GISBASE/etc/gui/icons. When the silk icon set is selected in the new wxGUI, it uses the icons in $GISBASE/docs/html/icons/silk.

In the docs called from wxGUI, you can see both the classic and silk icons, drawn from $GISBASE/docs/html/icons and $GISBASE/docs/html/icons/silk.

Martin and I agree that all the icons should be put into one place. The question is where. The original place identified for GUI icon sets was $GISBASE/etc/gui/icons. However, Martin points out that there is a real convenience factor for doc page creation to have them in $GISBASE/docs/html/icons. In either place, we should probably have a structure like ../icons/grass; ../icons/silk; ../icons/newgrass; etc.

I have no problem with the $GISBASE/docs/html/icons location but wanted to see if there are any other considerations we should keep in mind as to where the GRASS 7 icon archive should live.

Michael
______________________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

2

Michael:

Martin and I agree that all the icons should be put into one place.
The question is where. The original place identified for GUI icon sets
was $GISBASE/etc/gui/icons. However, Martin points out that there is a
real convenience factor for doc page creation to have them in $GISBASE/
docs/html/icons. In either place, we should probably have a structure
like ../icons/grass; ../icons/silk; ../icons/newgrass; etc.

I have no problem with the $GISBASE/docs/html/icons location but
wanted to see if there are any other considerations we should keep in
mind as to where the GRASS 7 icon archive should live.

IMO $GISBASE/docs/html/icons seems very a strange place to put them,
while $GISBASE/etc/icons seems very natural. Their primary reason for existence is for the GUI program, the docs are reactionary to that..

note that some packagers (Debian...) will, for large softwares, split the docs from the main program package into a new -docs package. this is for a couple reasons- one is that some people (eg embedded, old hardware) want to save the disk space by not installing unneeded docs; another is to avoid redundancy on the package download servers by pushing as much platform-neutral data into a single "-any" package and then have a series of smaller -i386, -arm, -mips, etc. binary packages. Storing 11 copies of the same docs adds up when you support 11 hardware platforms.

The icons are platform neutral so not a problem for the server-space reason, but very much a problem for the user wants "core only" reason.

2c
Hamish

3

Hamish wrote:

> Martin and I agree that all the icons should be put into one place.
> The question is where. The original place identified for GUI icon sets
> was $GISBASE/etc/gui/icons. However, Martin points out that there is a
> real convenience factor for doc page creation to have them in $GISBASE/
> docs/html/icons. In either place, we should probably have a structure
> like ../icons/grass; ../icons/silk; ../icons/newgrass; etc.
>
> I have no problem with the $GISBASE/docs/html/icons location but
> wanted to see if there are any other considerations we should keep in
> mind as to where the GRASS 7 icon archive should live.

IMO $GISBASE/docs/html/icons seems very a strange place to put them,
while $GISBASE/etc/icons seems very natural. Their primary reason for
existence is for the GUI program, the docs are reactionary to that..

note that some packagers (Debian...) will, for large softwares, split
the docs from the main program package into a new -docs package. this
is for a couple reasons- one is that some people (eg embedded, old
hardware) want to save the disk space by not installing unneeded docs;
another is to avoid redundancy on the package download servers by
pushing as much platform-neutral data into a single "-any" package and
then have a series of smaller -i386, -arm, -mips, etc. binary
packages. Storing 11 copies of the same docs adds up when you support
11 hardware platforms.

The icons are platform neutral so not a problem for the server-space
reason, but very much a problem for the user wants "core only" reason.

IOW, the icons should really be installed into both docs/html/icons
(for the documentation) and etc/icons (for the GUI itself).

This would also help to facilitate making GRASS behave more like a
normal Unix package, with various components installed in
subdirectories of /usr (or /usr/local), rather than everything going
into a single directory.

In that regard, I would expect something like:

  old new

  <gisbase> /usr/lib/grass-<version>
  <gisbase>/bwidget /usr/lib/grass-<version>/bwidget
  <gisbase>/driver /usr/lib/grass-<version>/driver
  <gisbase>/etc /usr/lib/grass-<version>/etc
  <gisbase>/fonts /usr/lib/grass-<version>/fonts
  <gisbase>/bin/* /usr/bin/*
  <gisbase>/scripts/* /usr/bin/*
  <gisbase>/lib/* /usr/lib/*
  <gisbase>/docs/html /usr/share/doc/grass-<version>/html
  <gisbase>/include/grass /usr/include/grass
  <gisbase>/locale/* /usr/share/locale/*
  <gisbase>/man/man1/* /usr/share/man/man1/*

If GISBASE points at /usr/lib/grass-<version>, then it's probably just
a case of finding the documentation (HTML and man), and not explicitly
specifying $GISBASE/bin (or $GISBASE/scripts) when running GRASS
modules.

Finding the HTML documentation could be as simple as making
$GISBASE/docs a symlink to GRASS' document directory if it's outside
of $GISBASE. For the manpages, g.manual can just specify the name
rather than a complete path, and rely upon MANPATH being set for the
case where everything is under $GISBASE.

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

4

Hi,

2008/8/6 Glynn Clements <glynn@gclements.plus.com>:

[...]

IMO $GISBASE/docs/html/icons seems very a strange place to put them,
while $GISBASE/etc/icons seems very natural. Their primary reason for
existence is for the GUI program, the docs are reactionary to that..

note that some packagers (Debian...) will, for large softwares, split
the docs from the main program package into a new -docs package. this
is for a couple reasons- one is that some people (eg embedded, old
hardware) want to save the disk space by not installing unneeded docs;
another is to avoid redundancy on the package download servers by
pushing as much platform-neutral data into a single "-any" package and
then have a series of smaller -i386, -arm, -mips, etc. binary
packages. Storing 11 copies of the same docs adds up when you support
11 hardware platforms.

The icons are platform neutral so not a problem for the server-space
reason, but very much a problem for the user wants "core only" reason.

IOW, the icons should really be installed into both docs/html/icons
(for the documentation) and etc/icons (for the GUI itself).

the reasons you have mentioned make senses to me. I will fix silk
icons accordingly.

[...]

BTW, maybe also icons and images from lib/init/ could be moved to the new place.

gintro.gif -> gui/images ($GISDBASE/etc/gui/images)
*.ico -> gui/icons ($GISDBASE/gui/icons)
original GRASS icons - gui/icons/grass ($GISDBASE/gui/icons/grass)
Silk icons - gui/icons/silk ($GISDBASE/gui/icons/silk)

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

5

There are ones in ../lib/init too? What are they used for?

The packaging structure Glynn proposed is fine for linux, but is not so good for Mac. It is much better for installation on the Mac if GRASS goes into a *.app package (normally in /Applications/*.app), as both William Kyngesburye and Lorenzo Moretti. Also, using the Mac help system as they do makes GRASS help more accessible (i.e., in the help library rather than only from within GRASS) than showing it via a browser. I'm not sure what the packaging issues are for help, but the only difference this would make to main GRASS packaging is that $GISBASE would be a Mac *.app package folder rather than /usr/local.

I don't know how the /usr/local structure plays on Windows, but do know that apps normally reside in a My Programs directory.

Michael
______________________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Aug 6, 2008, at 4:24 AM, Martin Landa wrote:

Hi,

2008/8/6 Glynn Clements <glynn@gclements.plus.com>:

[...]

IMO $GISBASE/docs/html/icons seems very a strange place to put them,
while $GISBASE/etc/icons seems very natural. Their primary reason for
existence is for the GUI program, the docs are reactionary to that..

note that some packagers (Debian...) will, for large softwares, split
the docs from the main program package into a new -docs package. this
is for a couple reasons- one is that some people (eg embedded, old
hardware) want to save the disk space by not installing unneeded docs;
another is to avoid redundancy on the package download servers by
pushing as much platform-neutral data into a single "-any" package and
then have a series of smaller -i386, -arm, -mips, etc. binary
packages. Storing 11 copies of the same docs adds up when you support
11 hardware platforms.

The icons are platform neutral so not a problem for the server-space
reason, but very much a problem for the user wants "core only" reason.

IOW, the icons should really be installed into both docs/html/icons
(for the documentation) and etc/icons (for the GUI itself).

the reasons you have mentioned make senses to me. I will fix silk
icons accordingly.

[...]

BTW, maybe also icons and images from lib/init/ could be moved to the new place.

gintro.gif -> gui/images ($GISDBASE/etc/gui/images)
*.ico -> gui/icons ($GISDBASE/gui/icons)
original GRASS icons - gui/icons/grass ($GISDBASE/gui/icons/grass)
Silk icons - gui/icons/silk ($GISDBASE/gui/icons/silk)

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

6

Do we want to change icon locations for GRASS 6.4 or only GRASS 7. AFAIK, only the docs and GUI need the icons.

Michael
______________________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Aug 6, 2008, at 4:24 AM, Martin Landa wrote:

Hi,

2008/8/6 Glynn Clements <glynn@gclements.plus.com>:

[...]

IMO $GISBASE/docs/html/icons seems very a strange place to put them,
while $GISBASE/etc/icons seems very natural. Their primary reason for
existence is for the GUI program, the docs are reactionary to that..

note that some packagers (Debian...) will, for large softwares, split
the docs from the main program package into a new -docs package. this
is for a couple reasons- one is that some people (eg embedded, old
hardware) want to save the disk space by not installing unneeded docs;
another is to avoid redundancy on the package download servers by
pushing as much platform-neutral data into a single "-any" package and
then have a series of smaller -i386, -arm, -mips, etc. binary
packages. Storing 11 copies of the same docs adds up when you support
11 hardware platforms.

The icons are platform neutral so not a problem for the server-space
reason, but very much a problem for the user wants "core only" reason.

IOW, the icons should really be installed into both docs/html/icons
(for the documentation) and etc/icons (for the GUI itself).

the reasons you have mentioned make senses to me. I will fix silk
icons accordingly.

[...]

BTW, maybe also icons and images from lib/init/ could be moved to the new place.

gintro.gif -> gui/images ($GISDBASE/etc/gui/images)
*.ico -> gui/icons ($GISDBASE/gui/icons)
original GRASS icons - gui/icons/grass ($GISDBASE/gui/icons/grass)
Silk icons - gui/icons/silk ($GISDBASE/gui/icons/silk)

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

7

On Aug 6, 2008, at 10:01 AM, Michael Barton wrote:

There are ones in ../lib/init too? What are they used for?

The packaging structure Glynn proposed is fine for linux, but is not so good for Mac. It is much better for installation on the Mac if GRASS goes into a *.app package (normally in /Applications/*.app), as both William Kyngesburye and Lorenzo Moretti. Also, using the Mac help system as they do makes GRASS help more accessible (i.e., in the help library rather than only from within GRASS) than showing it via a browser. I'm not sure what the packaging issues are for help, but the only difference this would make to main GRASS packaging is that $GISBASE would be a Mac *.app package folder rather than /usr/local.

I don't know how the /usr/local structure plays on Windows, but do know that apps normally reside in a My Programs directory.

Shouldn't make a difference on OSX .app package - /usr/local/* vs. /usr/local/grass-x.x.x/* will install the same inside the app package as Contents/MacOS/*.

Also, for the help, I currently use a symlink in the OSX help system to the app package (and requires admin authentication to setup). This is one big problem that locks down the app to the installed location (the other being Qgis hard library linking to the GRASS libraries).

But I just discovered a way to use Python to register a help package at startup, so it looks like I can get rid of one app relocation limitation soon.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy

8

Michael Barton wrote:

There are ones in ../lib/init too? What are they used for?

gintro.gif is the splash screen, help_loc_struct.png is used from
helptext.html, which is displayed by the Help buttion in gis_set.tcl.
There are also some .ico files, but I don't know how they are used.

The packaging structure Glynn proposed is fine for linux, but is not
so good for Mac. It is much better for installation on the Mac if
GRASS goes into a *.app package (normally in /Applications/*.app), as
both William Kyngesburye and Lorenzo Moretti. Also, using the Mac help
system as they do makes GRASS help more accessible (i.e., in the help
library rather than only from within GRASS) than showing it via a
browser. I'm not sure what the packaging issues are for help, but the
only difference this would make to main GRASS packaging is that
$GISBASE would be a Mac *.app package folder rather than /usr/local.

I don't know how the /usr/local structure plays on Windows, but do
know that apps normally reside in a My Programs directory.

A single directory is preferable if you want GRASS to behave as a
monolithic application.

If you want it to behave as a collection of modules, the programs need
to go into $PATH, which means either installing the programs into a
particular location or ensuring that $PATH gets extended. Similar
issues exist for dynamic libraries and manual pages.

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

9

Hi,

2008/8/6 Glynn Clements <glynn@gclements.plus.com>:

Michael Barton wrote:

There are ones in ../lib/init too? What are they used for?

gintro.gif is the splash screen, help_loc_struct.png is used from
helptext.html, which is displayed by the Help buttion in gis_set.tcl.
There are also some .ico files, but I don't know how they are used.

They are used as window icons (at least) in wxGUI e.g. [1]. gintro.gif
and *.ico files are GUI-related so they should go to gui/ directory.

Martin

[1] http://grass.osgeo.org/grass-wiki/images/WxGUI-vdigit-fill-area.png

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

10

Hi,

2008/8/6 Martin Landa <landa.martin@gmail.com>:

[...]

original GRASS icons - gui/icons/grass ($GISDBASE/gui/icons/grass)
Silk icons - gui/icons/silk ($GISDBASE/gui/icons/silk)

done, in devbr6

http://trac.osgeo.org/grass/changeset/32741

Will be backported to trunk, let me know if you encounter any problems...

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

11

2008/8/6 Martin Landa <landa.martin@gmail.com>:

[...]

gintro.gif -> gui/images ($GISDBASE/etc/gui/images)
*.ico -> gui/icons ($GISDBASE/gui/icons)

done,

http://trac.osgeo.org/grass/changeset/32743

Anyway lib/init need some more cleaning, especially tcl files...

BTW: are we going to drop Tcl/TK GUI in grass7?

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *