[Clipart] Where to install?

[Jonadab the Unsightly One]

Matthew Gates <matthew at porpoisehead.net> writes:

>>     /usr/share/clipart
>>
>> Then after installing the 0.14 release of openclipart-0.14
>>
>>     /usr/share/clipart/openclipart-0.14

[and so forth]

This makes sense to me.

> I like the simplicity of this approach, but it's not clear how this
> would work on platforms that have alternative hierarchies - windows,
> OS X, and others like the more radical linux distros with their own
> directory layouts.

It's not possible to pick a standard location that will make sense on
both Windows and OS X, as well as Linux.  Therefore, there will have
to be a standard location for Windows, another standard location for
POSIX systems, and so on.  I think it's reasonable to have
/usr/share/clipart be the standard location for most POSIX systems, or
at least for LSB-compliant systems.

You could have an environment variable (such as CLIPART_PATH) that
tells where to find this directory, but I don't recommend it as a
general cross-platform solution.  For one thing, some very common
platforms (well, mainly one extremely commmon platform) have rather
draconian limits on the size of the environment, so that it's NOT
practical to have environment variables for every little thing like
this.  

Actually, the Windows Way to do this, as gross as it is, is to define
a registry key that lists the path.

Of course, we could say that on POSIX systems the default location is
/usr/share/clipart but that the environment variable CLIPART_PATH, if
defined, overrides that.  That makes a certain sense to me.  In fact,
I rather like it.

The Win32 equivalent would be something like the following...

1.  Applications: Start at step 2 to determine where to find clipart.
    
    Clipart Installers:  if the user chooses "Custom Install", let the
    user pick the path, but use the steps below to determine the
    default, and then store the resulting path in the registry key
    HKLM\Software\Microsoft\Windows\Current Version\ClipartFilesDir
    for posterity.  If the user does not choose "Custom Install", use
    the steps below to determine where to put the clipart.

2.  If the key HKLM\Software\Microsoft\Windows\Current Version
    contains a value called ClipartFilesDir, the value of that value
    is the directory where (system-wide) clipart repositories are
    stored.

3.  Otherwise, if 
    HKLM\Software\Microsoft\Windows\Current Version\CommonFilesDir
    exists, use the directory called Clipart within the directory
    that value specifies (creating the Clipart directory if
    necessary).

4.  Otherwise, if
    HKLM\Software\Microsoft\Windows\Current Version\ProgramFilesDir
    exists, use the directory called Clipart within the directory
    called Common Files within the directory that value specifies
    (creating the Common Files and/or Clipart directories if they do
    not exist).

5.  Otherwise, use C:\Program Files\Common Files\Clipart
    (creating those directories as necessary)

6.  If you get to step 5 and there is no drive C:, it's a fatal error,
    or you can attempt to recover by asking the user what on earth is
    going on.

This is for the system-wide repository, as with /usr/share/clipart for
POSIX systems.  

For the user-specific repository on Win32, I'd say just use a
directory called Clipart within the My Pictures directory within 
My Documents or, if My Pictures doesn't exist, put the Clipart
directory directly within My Documents (i.e., in the user's home
directory, wherever that happens to be).  There are standard ways to
determine the location of the My Documents directory; I'm pretty sure
the registry is involved here too, but I'm not a Windows programmer.

>> We could standardize upon this and then also make a basic Makefile
>> to be included with our packages that would make install to these
>> locations.

Do we have someone who groks makefiles?  I sure don't.

Also note that makefiles are probably only useful on POSIX systems.
(This doesn't mean it's not worth including one, only that we should
be aware it won't be any use to, say, Win32 users.)

>> Also, if we agreed upon this, we could set any future DMS clients to
>> download to this location.

Agreed.

>> This is a standard that should be shared amongst GIMP, Inkscape, other
>> Gnome Apps, OO.o, Klipart, etc. Do you all agree? I don't think there
>> is a standard for this. Thoughts?

If there's not a standard for this, there should be, and fdo an
obvious entity that could specify it.

>> I just looked through my system and Abiword and Inkscape both have
>> clipart under there own program folder name like this:
>>
>>     /usr/share/AbiSuite-2.2/clipart
>>
>>     /usr/local/share/inkscape/clipart
>>
> Exactly the sort of think that we want to avoid IMO.  

I concur.

> I checked inkscape's configure script and the location of the
> clipart is not customisable there.  Maybe we could submit improved
> configure scripts for these projects that allow the clipart
> directory to be specified as an option at package configuration
> time?

If you take the trouble to do that, also have it default to
$CLIPART_PATH/repository-name or, failing that,
/share/clipart/repository-name within the prefix dir.

(The prefix dir will generally be whatever the user specified with
--prefix, and we should honor that, although /usr is the recommended
value IMO.)

e.g., for Inkscape the repository-name could be inkscape-clipart, so
the default location with a prefix of /usr would come out to
/usr/share/clipart/inkscape-clipart

Also note that it doesn't do any good to have the configure script set
up the makefile to place the clipart in a different location unless
the application will also know to read from that location.

>> Yes I agree. Well, we need to know more about OO.o and how it finds
>> clipart and standard clip art paths

IMO, the way OO.o currently handled this (as of version 1.x) is a
kludge we would do well not to follow.  It was a good interim solution
for OO.o to support *something* for clipart, but it is IMO not a
long-term solution.

Does the new OO.o 2.x still do things the same way?  If not, it may be
worth looking at how they do it now.  If they're still doing it the
1.x way, I'd not bother with that, as it will obviously have to be
changed eventually.

> I'm unsure of how system wide environment variables are modified by
> different distro.  Gentoo has a directory /etc/env.d into which
> makes it pretty simple to add environment variables (if I'm
> interpretting it's purpose correctly).  I other distros have
> different mechanisms, and in some it'll probably be necessary to
> modify /etc/profile or something (ugly - especially for
> un-installations).  Not that this is directly a problem for us -
> rather is is something those that take on package creation for those
> distros need to worry about.

This is a problem we don't have to solve.  We can just say that if the
environment variable doesn't exist, the location is assumed to be
/usr/share/clipart

That way, distros (or users) who want to deviate from that directory
structure can define the environment variable however they want.  The
Win32-style method of popping up a dialog and asking the user stuff at
install time never really caught on in Unix culture.  OO.o uses it,
and Mozilla, and little else -- and even those apps are frequently
installed using the distro's package mechanism (rpmdrake, synaptic,
ports, portage, ...).

IMO, for POSIX systems, the documentation can tell the user that the
environment variable CLIPART_PATH is available to customize the path
where clipart is stored, but frankly most users will just leave it at
the default, which is fine.

> Yes.  The question is - what forum is best?  Having some co-ordination 
> between Gnome and KDE would be a good place to start.  I suppose this 
> sort of thing is the realm of freedesktop.org?

Yeah, I think so.  If freedesktop.org specifies it and Gnome, KDE, and
a couple of applications follow it, it should catch on and become a de
facto standard.

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/