On Thu, Mar 10, 2005 at 01:22:07PM +0000, tim hall wrote: > I've been keeping an eye on the situation with regards to icons in menu > entries for A/DeMuDi - The multimedia CDD. Most of you have read this before, > I apologise for not being used to the Debian mailing lists, I'm not > subscribed, so off-list replies will be appreciated. I hope I've actually > sent this to the right list this time.
Hello Tim, You might consider sending that to [EMAIL PROTECTED] Fortunately this is me and I read debian-policy. > My intention is to contact all the maintainers of apps included in DeMuDi > that > don't appear to have icons and encourage them to include them - Most of this > needs to happen upstream, otherwise the distro will become full of temporary > hacks. Part of the hiatus has been caused by my realisation that Debian icon > policy is rather unclear. After reading your email, I am not sure if you have checked the latest version of the menu manual. I have attempted to clean up the menu icon recommendation, so you should check it: <http://www.debian.org/doc/packaging-manuals/menu.html/> > This is an open posting that I'm intending to send to all maintainers of > multimedia packages that don't appear to have icons. Please could you let me > know if I have my facts right. ;-] Does this need to go on one of the Debian > wikis. [If exist?]. Is it possible / worthwhile / necessary to change policy > in line with what I've suggested below (fairly close to existing policy). How > could I change it for the better? So far the reference document for icon is the Debian menu manual. I would be happy to here your comments. > """ > 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. > """ what is 'Policy weeklys' ? > ?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.] The Debian menu policy does not cover .desktop. > 1. The icons should be in XPM format. Icons may also be provided in .PNG > format for future compatibility with freedesktop.org standards. What does mean the second sentence? > 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. It is possible to provide both 16x16 and > 32x32 pixel icons using the variables icon16x16 and icon32x32 so that the > user can configure menu to use one or the other.] Note that it is OK to use icons smaller than 32x32 pixels, so 16x16 is OK. > 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" This is outdated: the current menu manual read: 3.9. Entries for menu sections. ------------------------------- It is possible to add entries for menu sections, but it is not mandatory since section entries are created automatically. However, this allows to specify fields for sections like `icon' and `sort'. The syntax for menu sections entries is the same as for regular entries, the `section' field holding the name of the parent section. For example ?package(local.games): needs="text" title="Games" section="/" sort="001" will sort `Games' first. > The other problem specific to A/DeMuDi is that having an independent > top-level > 'Sound' or 'Audio' menu section breaks Debian Menu Policy. What is exactly the problem ? It is obvious that Debian and DeMuDi needs different menu policies. Do you need a feature so that menufiles can specify both a Debian Menu Policy compliant section and a Demudi section ? I think you can do that using translate_menus (translate demudi->section). Cheers, -- Bill. <[EMAIL PROTECTED]> (Debian menu maintainer) Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
