[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The current policy on xpm/xbm icons



apharris@burrito.onshore.com (Adam P. Harris) writes:

> Daniel, for starters, this should probably be raised as a bug against
> debian-policy, just to make sure taht we don't forget about it.  We
> are underway in debian-policy on finding a new way to maintain policy.
> Right now, there basically *is* no policy editor.  Submitting a bug
> will make sure that someone at least looks at this problem.  Assuming
> it is a policy problem, an assumption with which I am not completely
> comfortable.

Ok; I'll file a bug against debian-policy.  I may try first though to see 
if there's something all of us window-manager packagers can agree on.

> > 1) there is a central place for icons that packageA wishes to make
> >    available to all other packages.  (for example, the
> >    xemacs20-support package might place xemacs.xpm in this location)
> >    - the docs to the menu package suggest
> >    /usr/X11R6/include/X11/{bitmaps,pixmaps} for this, but other
> >    possibilities exist (some packages are already using
> >    /usr/share/icons for this purpose)
> 
> Isn't this specified in FHS?

I was hoping it was; however, all I can find in the FHS is the mention 
that /usr/X11R6 is for the use of X windows, and that certain symbolic 
links are mandated - this implies (among other things) that the directory
/usr/X11R6/include must exist, but doesn't say what must be placed in
this directory or its subdirectories, if any.  The whole /usr/share
discussion is too vague to be useful.

> > 2) There's a defined policy on how a package should choose where to
> >    put icons that it uses internally (for example, the .xpm files that 
> >    come in xemacs20-support that are used by w3 fall into this
> >    category).  This need not be anything too definite; even a policy
> >    that says 'somewhere under /usr/share/{package}' is better than a 
> >    policy that says ''.
> >    It would probably be a good idea if window managers had stricter
> >    guidelines about where to put icons than other packages, as wm's
> >    tend to all use their icons for the same purpose.
> 
> Why is this really necessary?  This almost seems like too much detail
> for the Policy document.

Well, this last bit is probably overkill, but it would be nice if the
window managers were all consistent, so that a user would know that if
they wish to use the fvwm95 icons in afterstep, they need to put
/usr/X11R6/lib/X11/fvwm95/pixmaps on their path searched for pixmaps.
This might develop over time as a consensus, but considering how far
apart the current icon-location schemes are, it seems unlikely.

> > 3) Window managers are given a directory into which they must not 
> >    put any icons but which they must search for icons - this should be 
> >    something under /usr/local or /usr/share/local or similar.  The
> >    idea, of course, is to allow the local sysadmin to add her own
> >    icons to be used by all installed window managers.
> 
> A very nice idea.

This should at least be easy to reach a consensus on - all it entails
is a simple addition to one little config. file.

> > 4) This decision about icons becomes actual policy, rather than just a
> >    vague consensus followed by packagers who hear about it through the
> >    grapevine.
> 
> Yes that would be nice, though, while delegating out to FHS/FSSTD what
> is their to determine, and not getting too nit picky.
> 
> In many situations such as this, i.e., SGML sub-policy, menu
> sub-policy, emacs-common sub-policy, a motivated party builds
> consensus and formulates a sub-policy.  I think this issue is suitable
> for such an effort.

Ok; I'll be sending out an email soon then to all the current window
manager maintainers to see if we can form a consensus on some of these 
locations - at the very least I'd like to get the directories for (1)
and (3) settled.  I'm also going to talk to the fvwm-common maintainer 
about what to do with the plethora of icons currently in
/usr/X11R6/include/X11/pixmaps.


Reply to: