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

Bug#27869: marked as done ([REJECTED] Icon location policy)



Your message dated Tue, 20 Jun 2000 16:46:15 +0100
with message-id <20000620164615.A1075@polya>
and subject line Bug#27869: [REJECTED] Icon location policy
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Darren Benham
(administrator, Debian Bugs database)

--------------------------------------
Received: (at submit) by bugs.debian.org; 13 Oct 1998 15:13:17 +0000
Received: (qmail 8914 invoked from network); 13 Oct 1998 15:13:15 -0000
Received: from jhuml1.hcf.jhu.edu (128.220.2.86)
  by master.debian.org with SMTP; 13 Oct 1998 15:13:15 -0000
Received: from cush (ppp77.hcf.jhu.edu [128.220.222.77])
 by jhmail.hcf.jhu.edu (PMDF V5.2-29 #26381)
 with ESMTP id <01J2X4PKAN70DBGN8S@jhmail.hcf.jhu.edu> for
 submit@bugs.debian.org; Tue, 13 Oct 1998 11:12:56 EDT
Received: from martind by cush with local (Exim 1.891 #4 (Debian))
	id 0zT66z-0003Kn-00; Tue, 13 Oct 1998 11:11:45 -0400
Date: Tue, 13 Oct 1998 11:11:42 -0400
From: Daniel Martin <dtm12@jhunix.hcf.jhu.edu>
Subject: [PROPOSED] Icon location policy
To: submit@bugs.debian.org
Cc: fizbin-wmpeople@master.debian.org
Message-id: <87emscqyxd.fsf@cush.dyn.ml.org>
MIME-version: 1.0 (generated by tm-edit 7.108)
X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald"
Content-type: text/plain; charset=US-ASCII
Lines: 129

Package: debian-policy
Priority: wishlist

This is a proposal to debian-policy in accordance with the method
Manoj has set up using the Bug Tracking System for proposed policy
changes.

This covers the locations of icons.
------------------------------------------------------------------
Rationale

   There currently is no policy on where icons should end up; (the only
   thing approaching policy is the documentation that comes with the menu
   package - no, the FHS doesn't specify this even though it should) as a
   result, xpm icons can end up almost anywhere. This makes it difficult
   to write icon paths that do what users expect; that is, to configure
   our respective window managers so that all the proper icons are found.

   The Debian 2.0 (i.e. hamm) practice among the fvwm* crowd was to dump
   all icons into /usr/X11R6/include/X11/{bitmap,pixmap} - this has at
   least two problems:
    1. icons are shareable data, and as such should really wind up
       somewhere under /usr/share.
    2. If all window managers place their icons in one central directory,
       there's bound to eventually be collisions. While these can be
       papered over with a Replaces: header, the better solution is for
       this collision to never happen in the first place. (One stupid
       little pixmap is the reason that the hamm fvwm95 is listed as
       Replace:-ing the bo afterstep)

   Also, this system doesn't really give the local sysadmin a place to
   put her own icons where she can be confident they won't be overridden
   by some installed package. There should be a place under /usr/local
   that all window managers look in to find icons as well.

Requirements for packages which supply icons

   Packages that have some icon which identifies them (like the
   xemacs.xpm icon in xemacs20-support) should place that icon into
   /usr/share/icons/. Such icons should have a name that is specific to
   that package. (so "icon.xpm" should only be used by the "icon"
   package) If packages have some sort of "mini" icon that identifies
   them as well, it should go into /usr/share/icons/mini/ and should have
   a filename starting with "mini-" or "mini.".
       
   The rationale for choosing /usr/share/icons/ over /usr/share/pixmaps/
   is that we're not talking about just .xpm files anymore. The
   rationale of a second directory for mini icons is to keep down on 
   directory clutter. The rationale for starting the mini icon with
   "mini" is that some window managers which can make nice use of mini 
   icons in menus lack the ability to specify a separate icon path for 
   "regular size" and "mini" icons.

   Packages with icons intended for use only by themselves should place
   those icons somewhere under /usr/lib/<package> or /usr/share/<package>
   (or even /usr/X11R6/lib/<package> or /usr/X11R6/lib/X11/<package>)
   Specifically, these icons should not go into areas used by multiple
   packages like /usr/share/icons or /usr/X11R6/lib/X11/include/pixmaps.
   If a package has a large number of such files, they should probably
   get split off into a separate "Architecture: all" package which stores
   them under /usr/share/<package>.
   
Requirements for packages which use other packages' icons
       
   Now, window managers when searching for icons should (by default)
   search in this order:
     * User's ~/.<package>/icons         (optional)
     * User's ~/.icons
     * /usr/local/share/<package>/icons  (optional)
     * /usr/local/share/icons
     * /usr/share/<package>/icons        (optional)
     * /usr/share/icons
     * Backwards compatibility path of:
          + /usr/share/pixmaps
          + /usr/X11R6/include/X11/pixmaps
          + /usr/X11R6/include/X11/bitmaps
          + /usr/X11R6/include/pixmaps
          + /usr/X11R6/include/bitmaps

   A few notes about the three paths I listed with "optional":
    1. A maintainer can leave out any or all of these paths, although
       leaving out /usr/local/share/<package>/icons while including
       /usr/share/<package>/icons seems a bit odd.
    2. If for your package it makes more sense to internally store your
       icons under /usr/share/<package>/iconthingys (that is, if it makes
       more sense to use a different path under /usr/share/<package>/),
       use that instead, and change the name of the directory searched
       under /usr/local/share/<package>/ to match this.
    3. If it makes sense to use a differently named user-specific,
       package-specific icon directory go ahead and do so, but document
       it in the /usr/doc/<package>/README.debian file.
     
   Actually, documenting the default icon path in
   /usr/doc/<package>/README.debian (even if it's exactly this) is 
   generally a good idea.
     
   Also, other directories may be added at any point in the path (for 
   example, /usr/local/share/pixmaps) by a maintainer if they feel
   like it.

   In addition, this combined with current /usr/local policy implies that
   in the postinst window managers should attempt to create the directory
   structure under /usr/local that appears in their icon path. Also, the
   postinst must not fail if these directories couldn't be created.
   Window managers (in fact any package) must not contain anything in the
   /usr/local tree.

Postscript
       
   Redhat appears to follow something like this - the RedHat 5.1 packages
   I checked (AnotherLevel and fvwm2-icons) seem to use /usr/share/icons
   as a place to dump icons (which makes gnome's use of
   /usr/share/pixmaps a bit surprising). RedHat compatibility in this
   regard would be nice for those people installing commercial apps that
   only come as RPMs.

   This proposal represents the consensus of those maintainers of
   window managers as cared to participate in the discussion.
   Specifically, at least the maintainers of the fvwm* packages, KDE
   packages, and window maker packages cared to participate.  The
   maintainers of other packages, while they haven't signed off on
   this specifically, have received copies of this and haven't
   objected. 

   It is intended that window managers will implement the new search
   path in slink or in the first upload in whatever is to be after
   slink.  Packages which supply icons for general use will move the
   locations of their icons into /usr/share/icons after slink.  This
   should provide for a smooth transition.
---------------------------------------
Received: (at 27869-done) by bugs.debian.org; 20 Jun 2000 21:22:57 +0000
>From J.D.Gilbey@qmw.ac.uk Tue Jun 20 16:22:57 2000
Return-path: <J.D.Gilbey@qmw.ac.uk>
Received: from mserv1a.u-net.net [195.102.240.34] 
	by master.debian.org with esmtp (Exim 3.12 2 (Debian))
	id 134VU1-0002IH-00; Tue, 20 Jun 2000 16:22:57 -0500
Received: from [195.102.197.154] (helo=polya)
	by mserv1a.u-net.net with esmtp (Exim 2.10 #63)
	id 134VUU-0000AG-00
	for 27869-done@bugs.debian.org; Tue, 20 Jun 2000 22:23:27 +0100
Received: from jdg by polya with local (Exim 3.12 #1 (Debian))
	id 134QEB-0000HR-00; Tue, 20 Jun 2000 16:46:15 +0100
Date: Tue, 20 Jun 2000 16:46:15 +0100
From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>
To: 27869-done@bugs.debian.org
Subject: Bug#27869: [REJECTED] Icon location policy
Message-ID: <20000620164615.A1075@polya>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Delivered-To: 27869-done@bugs.debian.org

Well, it was an important subject but no concensus was ever reached.
We'll have to leave it for the time being and resurrect it if
appropriate.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/



Reply to: