|--==> 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 [EMAIL PROTECTED] 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
