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

Re: Icon sizes for menus

Joey Hess <joey@kite.ml.org> writes:
> > Do we have any GIMP experts?  Can we distribute a GIMP colourmap with
> > the menu package?  I know Netscape has a predefined colourmap - is it
> > too big for our purposes?  The standard Win95 icons manage to look
> > good on a 16 colour display.
> I was thinking perhaps the menu package docs could include a xpm file with
> the colormap we come up with in it. xpm files are easy to read (as text
> files, even).

Here's the standard colourmap from GIMP 0.99.1.  Very readable.  Looks
to be the same as the standard MS 16 colour palette too (with
additional grey levels).

GIMP Palette
# Default -- GIMP Palette file
255 0 0	Red
255 0 255	Magenta
0 0 255	Blue
0 255 255	Cyan
0 255 0	Green
255 255 0	Yellow
127 0 0	Dark Red
127 0 127	Dark Magenta
0 0 127	Dark Blue
0 127 127	Dark Cyan
0 127 0	Dark Green
130 127 0	Dark Yellow
0 0 0	Black
25 25 25	Gray 10%
51 51 51	Gray 20%
76 76 76	Gray 30%
102 102 102	Gray 40%
127 127 127	Gray 50%
153 153 153	Gray 60%
178 178 178	Gray 70%
204 204 204	Gray 80%
229 229 229	Gray 90%
255 255 255	White

> If we did pick a colormap that match the one used by netscpae, would
> netscape (and other programs) actually share colors from it? I didn't think
> they could.

I dont' see why it shouldn't.  My understanding of X11 colourmaps is
that there's one shared between applications (unless the application
requests its own private one - which results in colourmap flashing).
One application doesn't know if another is using the colours in the

> It should be possible to wrote a program that reduces an existing image to
> our chosen colormap. I think that fvwm comes with such a program. Or course,
> hand treaking after running the program would be a good idea.

Unfortunately, when working with icons as small as 16x16, it's more up
to good initial design than simply shrinking an existing larger
picture.  A good start, though, no doubt, and better than nothing.

> > If we distribute pixmaps with names such as 'pixmap.{16|32|48}.xpm',
> > then I'll happily hack fvwm95 to look for the appropriate file (and
> > fall back!)  depending on a dynamic preferred icon size setting.
> The menu program could probably handle something similar. There is currently
> a entry in the menu files for the icon to use, which is right now the full
> filename of the icon. Maybe that could be changed to just be the basename of
> the icon, and "16|32.xpm" gets tacked on the end to generate the actual icon
> filename.

Ah, but then the user won't be able to switch between large and small
icons without rerunning the 'update-menus' program.  And either
they'll need to have a complete set of entries in their ~/.menu
directory, or the system will have a global configuration for icon

> > PS. The latest LJ arrived this morning - an excellent letter praising
> > Debian from a user, and the XBanner article was written on a Debian
> > box.  It would have been nice if the author had mentioned the Debian
> > XBanner package in the article, but at least the screen shots had the
> > 'Debian GNU/Linux' xdm login :)
> I maintain xbanner, and I worked closely with the upstream author in getting
> the debian package set up. I think that he had already submitted the article
> by the time I got the package out, so you can blame me that the article
> doesn't point to it. You can also blame me for the currently (IMHO) ugly
> 'Debian GNU/Linux' xdm login. ;-)

Yup, it's horrible :) Fortunately, it only flashes up for an instant
before my previously configured 'xv -root...' replaces it :)

I was helping a new Linux user with their Red Hat distribution today.
They were mystified by the fact that the menu entries looked good,
full of programs and icons, but virtually none of them worked.  He
asked me how he could customise them.  Saying 'man fvwm95' isn't easy
when he's not used to these ways of working.

This experience focused my thoughts.  If we're supplying menus with
programs, then they should really work.  This really means packages
such as xbase should include the menufiles for things like xterm, and
not be hard wired into the window manager menus (unless they can't
utilise the menu scheme).

Best wishes, all who reached this far! :)


Reply to: