AGNULA/DeMuDi Menu Icon Guidelines
Re: A/DeMuDi bugs:
[ #909 ] ICONS for all sound apps
[ #504 ] Icons are missing in KDE menu items
My hunt for a solution to this particular issue has led me thus far:
This is an open posting that I'm preparing to send to all maintainers of the
remaining packages that don't appear to have icons. Please could you let me
know if I have my facts right. ;-]
----
"""
Many people have never been happy with the icons provided by debian.
There are not enough of them, they are inconsistent in style, and the
low resolution and limited colors make them look like escapees from
1989. Lots of users don't bother with them.
Debian needs a consistent policy on where icons go - the icon policy is still
"something to be addressed" in future Policy weeklys; however, the
few policy weeklys published since then don't seem to address it at
all.
"""
These guidelines are my attempt to address it from the perspective of
AGNULA/DeMuDi. They are based on Debian Policy with a view to incorporating
freedesktop.org standards. I am only focussing on achieving coherence amongst
multimedia applications here.
----
Please, make sure the icons you specify are always available on the system.
So, if you want to have an icon with your menu entry, the preferred method is
to supply the icon with that package. Also, to prevent the distribution of
icons files to turn too much into a mess, please put all icon files in the
directory /usr/share/pixmaps - It's all static shareable
architecture-independent data.
The use of /usr/X11R6/include/X11/pixmaps/ for .XPMs seems to be deprecated,
but some packages still use it. KDE keeps its icons (mostly .PNGs) in a
sorted-by-theme tree based at /usr/share/icons. Most other WMs read .XPMs out
of /usr/share/pixmaps this latter is the standard.
A package should provide a menu file /usr/lib/menu/<package-name> that
contains information about each program it likes to make available in the
menus.
?package(ecasound2.2):needs=text section=Apps/Sound\
title="ecasound2.2" command="/usr/bin/ecasound -c" \
icon="/usr/share/pixmaps/ecasound.xpm" \
icon16x16="/usr/share/pixmaps/eca_16.xpm" \
icon32x32="/usr/share/pixmaps/eca_32.xpm"
You may also want to include a .desktop file using the freedesktop.org defined
Desktop Entry Standard. I don't know enough about this yet.
1. The icons should be in XPM format. Icons may also be provided in .PNG
format for future compatibility with freedesktop.org standards.
2. The icons (.XPMs) may not be larger than 32x32 pixels, although smaller
sizes are ok. 48x48 or even larger may be acceptable for .PNGs. This
restriction applies only to icons referenced
from /usr/lib/menu/<package-name> for application menus. KDE and GNOME seem
to use 16x16 icons which requires an icon16x16 entry in the
package's /usr/lib/menu file. You can provide both 16x16 and 32x32 pixels
icons using the variables icon16x16 and icon32x32 so that the user can
configure menu to use one or the other.
3. The background area of the icon should be transparent, if possible.
----
Additionally:
Apparently it's also possible to specify an icon for a sub-menu. However, if
each package would supply its own icons for the sub menus we can never be
sure that the icon files are available. Thus, only the menu package is
allowed to specify icons for sub menus. The syntax for this is:
X11 Apps menu/apps /usr/share/pixmaps/icon.xpm "Editors"
I'm not sure of the location of this file? Any guesses?
The other problem specific to A/DeMuDi is that having an independent top-level
'Sound' or 'Audio' menu section breaks Debian Menu Policy.
I have designed a set of generic sound-application group icons, which could be
used more widely, especially if I were to convert them to .XPMs and knew
where we should put the configuration file and preferably which upstream
package they should be included in (currently demudi-artwork). These can
currently be found in (surprise!) /usr/share/pixmaps/ as .PNGs and may be
freely used (of course) by maintainers who do not wish to design their own,
for whatever reason.
I'd value any thoughts you all might have on the matter.
cheers
tim hall
http://glastonburymusic.org.uk
Reply to: