[GRASS-dev] question about icons in GRASS 7

[Glynn Clements]

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 at gclements.plus.com>