Re: [a-users] AGNULA/DeMuDi Menu Icon Guidelines
|--==> tim hall writes:
th> Re: A/DeMuDi bugs:
th> [ #909 ] ICONS for all sound apps
th> [ #504 ] Icons are missing in KDE menu items
th> My hunt for a solution to this particular issue has led me thus far:
th> This is an open posting that I'm preparing to send to all maintainers of the
th> remaining packages that don't appear to have icons. Please could you let me
th> know if I have my facts right. ;-]
Tim, I think this is a good start. Note that I'm among the
command-line-addicted ones, but I consider the issue important as
well, and I hope other maintainers will be as sensitive.
Typically Debian policy changes are hard to achieve, but this case
definitely worth the effort. Moreover the task could be possibly
easier because there's a separate document for the menu policy than
the general one:
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-menus
http://www.debian.org/doc/packaging-manuals/menu-policy/
We may want to involve debian-devel@l.d.o in this discussion.
th> ----
th> """
th> Many people have never been happy with the icons provided by debian.
th> There are not enough of them, they are inconsistent in style, and the
th> low resolution and limited colors make them look like escapees from
th> 1989. Lots of users don't bother with them.
th> Debian needs a consistent policy on where icons go - the icon policy is still
th> "something to be addressed" in future Policy weeklys; however, the
th> few policy weeklys published since then don't seem to address it at
th> all.
th> """
th> These guidelines are my attempt to address it from the perspective of
th> AGNULA/DeMuDi. They are based on Debian Policy with a view to incorporating
th> freedesktop.org standards. I am only focussing on achieving coherence amongst
th> multimedia applications here.
th> ----
th> Please, make sure the icons you specify are always available on the system.
th> So, if you want to have an icon with your menu entry, the preferred method is
th> to supply the icon with that package. Also, to prevent the distribution of
th> icons files to turn too much into a mess, please put all icon files in the
th> directory /usr/share/pixmaps - It's all static shareable
th> architecture-independent data.
Ok. I'd add that the icon file name should be:
/usr/share/pixmaps/<package>.xpm
in case of a single icon or
/usr/share/pixmaps/<package>-<icon0>.xpm
/usr/share/pixmaps/<package>-<icon1>.xpm
..
/usr/share/pixmaps/<package>-<iconN>.xpm
in case of multiple ones, where iconX is an arbitrary string
characterising the icon.
th> The use of /usr/X11R6/include/X11/pixmaps/ for .XPMs seems to be deprecated,
th> but some packages still use it. KDE keeps its icons (mostly .PNGs) in a
th> sorted-by-theme tree based at /usr/share/icons. Most other WMs read .XPMs out
th> of /usr/share/pixmaps this latter is the standard.
Yes, that's true.
th> A package should provide a menu file /usr/lib/menu/<package-name> that
th> contains information about each program it likes to make available in the
th> menus.
th> ?package(ecasound2.2):needs=text section=Apps/Sound\
th> title="ecasound2.2" command="/usr/bin/ecasound -c" \
th> icon="/usr/share/pixmaps/ecasound.xpm" \
th> icon16x16="/usr/share/pixmaps/eca_16.xpm" \
th> icon32x32="/usr/share/pixmaps/eca_32.xpm"
Ok, this already done by most of the packages though, at least the
sound related ones.
th> You may also want to include a .desktop file using the freedesktop.org defined
th> Desktop Entry Standard. I don't know enough about this yet.
th> 1. The icons should be in XPM format. Icons may also be provided in .PNG
th> format for future compatibility with freedesktop.org standards.
Yes, XPM is widely used as icon format, I think would should push on it.
th> 2. The icons (.XPMs) may not be larger than 32x32 pixels, although smaller
th> sizes are ok. 48x48 or even larger may be acceptable for .PNGs. This
th> restriction applies only to icons referenced
th> from /usr/lib/menu/<package-name> for application menus. KDE and GNOME seem
th> to use 16x16 icons which requires an icon16x16 entry in the
th> package's /usr/lib/menu file. You can provide both 16x16 and 32x32 pixels
th> icons using the variables icon16x16 and icon32x32 so that the user can
th> configure menu to use one or the other.
th> 3. The background area of the icon should be transparent, if possible.
th> ----
th> Additionally:
th> Apparently it's also possible to specify an icon for a sub-menu. However, if
th> each package would supply its own icons for the sub menus we can never be
th> sure that the icon files are available. Thus, only the menu package is
th> allowed to specify icons for sub menus. The syntax for this is:
th> X11 Apps menu/apps /usr/share/pixmaps/icon.xpm "Editors"
th> I'm not sure of the location of this file? Any guesses?
Making menu authoritative for sub-menus icons is a good idea IMO. I'd
suggest to use:
/usr/lib/menu/menu
to hold such information:
?package(menu):needs="X11" section="Apps/Sound" icon="/usr/share/pixmaps/icon.xpm"
th> The other problem specific to A/DeMuDi is that having an independent top-level
th> 'Sound' or 'Audio' menu section breaks Debian Menu Policy.
th> I have designed a set of generic sound-application group icons, which could be
th> used more widely, especially if I were to convert them to .XPMs and knew
th> where we should put the configuration file and preferably which upstream
th> package they should be included in (currently demudi-artwork).
The demudi-artwork package was growing to much, I've split it in
several packages. There relevant one is demudi-pixmaps.
th> These can
th> currently be found in (surprise!) /usr/share/pixmaps/ as .PNGs and may be
th> freely used (of course) by maintainers who do not wish to design their own,
th> for whatever reason.
I've converted them to .xpm, see:
http://demudi.alioth.debian.org/browser/demudi-pixmaps/trunk/
(hope it works, alioth is having problems in this period)
th> I'd value any thoughts you all might have on the matter.
Keep it on!
Cheers,
Free
Reply to: