On Wed, 14 May 2003 00:30:29 -0700 Chris Waters <xtifr@debian.org> wrote: > On Tue, May 13, 2003 at 05:47:15PM -0400, David B Harris wrote: > > > 32x32 is *huge* in a menu, and 48x48 is insane. At least for common > > use today :) > > I agree -- icons in the menu should be about the same size as the > text, or maybe a little larger. It's a menu, not an image-viewing > tool. :) Right :) On the other hand, we would probably have more icons listed in /usr/lib/menu/* if we could just use upstream's. > > If it's going to be changed, there has to be the basic > > assumption that the Right Thing(tm) will be done, either via dynamic > > resizing on the part of the menu app, or conversion in the menu > > method(the latter will always work). Otherwise, it needs to be left > > as-is. > > Actually, there's another option: just add some new variables, and, as > with title/longtitle, put a function in /etc/menu-methods/menu.h to > choose the best one, which the user can comment out or edit. That > should satisfy everyone, and the only tricky part is coming up with > the new variable names and documenting them. "Choose the best one" implies having multiple icons of different sizes, right? If that's the case, it won't work everywhere. It'll only work for packages which supply menu icons of different sizes. Given how trivial it would be to add a scaled pixmap cache for a given menu method and have said method point the generated menu entry to the scaled and cached pixmap, I still think that would be a better solution. Let the menu method decide what size they should be; chances are, people using a given menu app will be using similarly-sized items. And this is, of course, *just* for those menu apps which don't know how to scale pixmaps. There are fewer of them today than there used to be, and the biggies (GNOME and KDE) did it last time I checked. If you didn't mean "choose the best one from what's in the package", could you clarify? :)
Attachment:
pgpnV69JtAokw.pgp
Description: PGP signature