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 <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
