On Tue, Nov 16, 1999 at 03:00:30PM +0000, Julian Gilbey wrote:
> > If you don't intend for it to be used as an icon, don't put it there.
> > Meanwhile, /usr/{something}/pixmaps could reasonably be interpreted as a
> > respository for all sorts of .xpm's, regardless of their purpose.
>
> A thought on this last point:
>
> I would be happy to see /usr/share/{bitmap,pixmap} -> /usr/share/icons
> symlinks. In this way, things can be deposited in the most
> "appropriate" location, but users and programs will always know where
> to find the files: they will always be in /usr/share/icons and they
> will also always be in /usr/share/pixmaps.
I've revised my thinking again on this, especially after reading fvwm2's
manpage.
fvwm2 permits you to define an ImagePath:
ImagePath path
Specifies a colon separated list of directories in
which to search for images (both monochrome and
pixmap).
NOTE: ImagePath makes obsolete IconPath and Pixmap
Path commands in the next fvwm versions. In this
version all of the three commands are allowed.
The ImagePath may contain environment variables
such as $HOME (or ${HOME}). Further, a '+' in the
path is expanded to the previous value of the path,
allowing easy appending or prepending to the path.
For example:
ImagePath $HOME/icons:+:/usr/include/X11/bitmaps
When they say "monochrome", they mean .xbm's. Why not just have a
/usr/share/image directory in which images of any format or size can be
placed? It sure would make things simpler.
I don't think there are any apps out there that automatically try to parse
every image in a directory, and yet only support one or two formats, thus
bombing on anything unfamiliar.
It is universal practice to identify an image type by file extension, so I
don't anticipate any real name collision problems, either.
Let people put images big or small in this directory. It is up to those
writing window manager config files (us or the user) to make sure we don't
give them a 1600x1200 icon for xterm.
> I'm also undecided as to what to do with the /usr/X11R6 directories.
> I would be happy to leave them alone, but also happy to see them
> become symlinks to /usr/share/icons instead.
If the -policy group reaches consensus about icon directories (however
general or specific) outside the /usr/X11R6 hierarchy, then we can start
asking people to move before it becomes policy. But I'd like XFree86
(specifically, xlib6g) to be the caboose package, converting only after all
others have done so. Because I am impatient person, I will probably harass
those who move too slowly for me. :)
There is, however, a graver concern...
> Technical question: if xfree86-common were to move all of the icons
> currently in /usr/X11R6/lib/X11/{pixmaps,bitmaps} into
> /usr/share/icons and then set up symlinks, how badly would things
> break wrt dpkg? I'm certainly not advocating that we do anything
> before the potato release, though. Too much to go wrong.
It wouldn't *IF* everybody else moved out of the way first. But it occurs
to me that xlib6g would have to have a versioned Conflicts: with every
package that ever put stuff in those directories. If that's a very long
list I'm going to get antsy. I'd like it to happen but I really hate
godawful long package relationship lines in control.
I don't think it would be a good idea for the xlib6g preinst to actually
move files, though. That is, doing a mv on files owned by other packages.
That's a very nasty thing to do to dpkg and I'm sure the little iwj
homunculus inside dpkg would become enraged and destroy people's systems.
Anyway, my proposal is for /usr/share/images, where image data of any size
and type[1] can be stored. Then we can just tell all window managers to
look there for what they want. xlib6g can put its bitmaps there as well,
but eliminating /usr/X11R6/lib/{bit,pix}map demands more study. I do not
think it is feasible to remove it entirely. Leaving it as a symlink to
/usr/share/images is desirable, but presents problems.
[1] I think we should confine this definition to "image type" to stuff that
is basically an encoded bitmap. I can't yet make up my mind about vector
graphics formats; they should go there but it seems a slippery slope down
to PDF and PostScript, which to my mind definitely don't belong there.
OTOH, maybe we can get a nice sharp boundary by saying the vector graphics
format can't be Turing-complete, which PS and PDF are, aren't they?
--
G. Branden Robinson |
Debian GNU/Linux | Please do not look directly into laser
branden@ecn.purdue.edu | with remaining eye.
cartoon.ecn.purdue.edu/~branden/ |
Attachment:
pgp7IrNj8xark.pgp
Description: PGP signature