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

Re: Menu icons for packages



Last Thursday 10 March 2005 14:26, Bill Allombert was like:
> 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.
> You might consider sending that to menu@packages.debian.org. Fortunately
> this is me and I read debian-policy.

Hi Bill,

Thankyou, I shall refer future correspondence to that address, after I've 
taken your notes into consideration. I think this will considerably simplify 
the task.

> > 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/>

You are absolutely right, I didn't check before sending this time. Mea culpa, 
it's been such a long drawn out process. This is indeed clearer and means I 
can quote policy verbatim at the maintainers I'm aiming at. Thanks for 
cleaning up the recommendations, it renders most of this posting redundant.

> > 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.

Good, now I know where to send them. I will study the changes first.

> > """
> > 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' ?

TBH I don't know, this is an old quote that served at the time. I don't think 
it's relevant any more.

> >  ?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?

****

OK, the crux of the matter is that I would like to give some guidance on the 
inclusion of .pngs as well as .xpms. I can see that it may suffice to quote 
menu icon policy verbatim and include any discussion of .desktop & .pngs 
separately according to .desktop guidelines and make it clear that it is an 
option as opposed to debian policy. The important issue from my perspective 
is that .pngs should use /usr/share/pixmaps/ too as seems to be general 
practice. I want to be sure I'm not going to cause future confusion if I 
suggest this to lots of Debian multimedia maintainers.

****

> > 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.

Thanks for that. I probably wouldn't have registered that if you hadn't 
pointed it out.

> > 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).

This is a side note, put in for clearance. I am just checking that DeMuDi is 
as Debian policy compliant as practicable as part of a move towards 
_official_ CDD status, hopefully in the not too distant future. DeMuDi has 
always used translate_menus in the past, this may now be controlled by 
cfengine scripts, I will have to check with Free. Anyhow, it's clearly a 
non-issue, that's all I needed to know.

This started as a simple bug-report follow-up to a complaint that many DeMuDi 
menu items lacked icons, which is now no longer the case. I can now move on 
to fill in the gaps, make sure the menus look as good as possible without any 
vile hacks. I'm fairly sure Free has seen to this last point already. I now 
have about a month to try and pull it all in in time for the next 
AGNULA/DeMuDi release (1.2.1). Whee!

Thanks for taking the time to reply and put me out of my misery. ;-)

cheers,

--tim hall
http://glastonburymusic.org.uk/tim

--imagine a big red sine wave here, with knobs on--



Reply to: