Subject: wm-icons distribution

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 27 Mar 1999 16:10:40 +0300 (IDT)

This message is large. But it is not me who wanted to discuss fvwm-icons
(or wm-icons) questions here. :)
My server is down until tommorow. Fortunately, I can read web-based mail
archives on fvwm.org (updated once a day...)

Lets leave other types of icons, like decorations and side images, for now
and first discuss application icons. I think the word 'icon' refers to an
iconified picture of an application. Probably we need to refer to other
types of icons as images or decorations sitting in different directory tree.

Steve writes:
> The icons would probably be classed into subdirectories under
> ${prefix}/share/wm-icons, maybe by size (14x14, 16x16, 10x40), or maybe by
> a more vague notion like mini, std, side.  I suspect that one wouldn't get
> very far if we decreed "mini icons are 14x14".  Somone is going to say
> "well, my screen is so huge that I want 18x18 mini icons".  One way around
> this is to install both into icons/14x14 and icons/18x18, and make a
> symlink icons/mini to the appropriate one.

This is a good idea. We can have directory names based both on a size and on
a more common notion. For example, we can have directories 16x16/, 32x32/,
48x48, 64x64/ with mini/ symlinked to the actual directory, say 16x16/, and
std/ symlinked to 48x48/.

This all is very unusual (but nice!), because if we decide on this scheme we
don't subdivide all application icons on standard and mini, they are just
links to different sets which have exactly the same files. Now, if one
would want to add an icon, he must add it to every sized set, which has
own advantages (consistency and a wider user choice) and disadvantages
(difficult to create). Lets suppose we choose this scheme.

Configuration files will use forms mini/emacs.gif and std/emacs.xpm, and a
user can easily switch to another set without changing the configuration
(.fvwmrc) at all. Just resymlink. In this case, it is enough that ImagePath
points to a base directory, say, /usr/local/icons. To be more compatible
with the current icon scheme, where mini-icons sit in mini/ subdirectory of
standard icons, we can add to ImagePath also /usr/local/icons/std and then
refer to standard icons as emacs.xpm and to mini-icons as mini/emacs.xpm.

Here is, however, a practical problem here. Icons are not always resizable,
they only resizable if we have very qualitative original icons, this is not
our case, otherwise icons must be redrawn for each specific size. And we
must ensure that every sized set has all icons (emacs.xpm). I think we can
start with only two sizes (standard and mini) and then probably add others.
Or we can find artists to draw qualitative icons (Patrick? :) ).

So, must we recognize mini-icons just as a differnent set of icons without
any functional difference? It seems to be logical. KDE and GNOME behave
similarly. Although, GNOME creates mini-icons on the fly (by resizing down
standard icons .png) and KDE has a separate directory for mini icons,
created from standard icons (.xpm) by an automatical (or half-automatical)
process. the GNOME solution is currently not possible for most window
managers (which are not using imlib or the like). Am I wrong?

Dan Espen writes:
> If you have enough sub-directories, there is a performance penalty
> to be paid in all the searching unless you start referring to icons
> as "14x14/mini.destroy.xpm" in the window manager config file.
> I realize you probably wouldn't put both 14x14 and 16x16
> in your imagePath.

The only reason for creating 2 subdirectories 14x14/ and 16x16/ is that they
would contain exactly the same files. Otherwise one mini/ is more
preferable. You must have only one or none mini-icon directories in
ImagePath, not two.

And is not the previous scheme just more preferable? Not mini.emacs.xpm or
mini-emacs.xpm, but mini/emacs.xpm. This is also not the first scheme which
doesn't use the "mini." prefix in file names. Look at KDE, they have two
sets of icons: standard 32x32 and mini 16x16, while mini icons sit inside
mini/ and do not have any additional prefix.

> It might  be helpful to  identify how  many  categories of icons there
> could be.  These are a few I  can think of: "Desktop Icons", Textures,
> Titlebar  buttons,   mini-icons, color  theme, 2D vs.   flat,
> shaped vs. rectangular vs. square, color hungry, and size
> variations (small, medium, large?).

I suggest having more levels here, like:
  icons/    (different sizes, including standard & mini)
    size1/    (the same set
    size2/     of files in each)
  decorations/
    buttons/
    ..

or:
  icons/
    appl/
      size1/
      size2/
    appl-color-reduced/
      size1/
      size2/
    decorations/
      ..
    textures/
      ..

Complex, isn't it? This is why I suggest first to discuss only application
icons.

Larry Gensch writes:
> I think size is more useful (just an opinion, though).  Personally, I
> tend to dump all my icons into a single directory.

Dominik Vogt writes:
> A naming scheme that produce 'ls' listings that are sorted by
> icon size would be very nice. Perhaps some kind of prefix would
> help (e.g. size classes A, B, C, D, E or whatever).

I think it is just natural that every directory contains icons of the same
size. Every such directory has a full set of icons of the same size.
You can find all installed sizes by `ls -d $ICONS_BASE/[0-9]*x[0-9]*`
or yet better: wm-icons-config --size-sets.

Concerning icon names. I think icons must be all lower-cased with one point
in the name before .xpm extention with dash used as word seperator, say
fvwm-pager.xpm.

So, putting it all together, we can have:

/usr/local/icons/
  16x16/
  any-other-size/
  48x48/
  48x48-other-style/  (?)
  mini/ -> 16x16/
  std/  -> 48x48/

where /usr/local/icons is configured by *wm-icons makefile and returned
by wm-icons-config --base-dir or similar.

Here is one of the two possible variants for .fvwm2rc:

# ==== Variant 1 ====
ImagePath /usr/local/icons
Style "emacs*" Icon std/emacs.xpm, MiniIcon mini/emacs.xpm

# ==== Variant 2 ====
ImagePath /usr/local/icons/std:/usr/local/icons
Style "emacs*" Icon emacs.xpm, MiniIcon mini/emacs.xpm

First variant is more consistent, but second is more compatible with the
way it is now. I am not sure which is better. One can use any.

Larry Gensch writes:
> Speaking of which, I have a rather large collection of icons that I've
> created and collected over the last couple of years.  I imagine that
> a lot of other people on this list have done so as well.  Is somebody
> going to act as a repository for these, providing some common color
> choices, etc. and cleaning up copyright/trademark issues?

Please upload any original icons you have tar-gzipped to
  ftp://milonka.ml.org/incoming/fvwm-icons/    (starting tomorrow)

If we choose to have sets of icons that differ by the size, we must decide
on the full list of icons in every such set (emacs, netscape, games,
fvwm-modules..) and create all these with different sizes. I am not sure yet
if this is practically possible, but it seems to be nice.

Regards,
Mikhael.

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Steve Robbins <[email-masked]>
Date: Mon, 29 Mar 1999 01:32:06 -0500 (EST)

> types of icons as images or decorations sitting in different directory tree.

OK, we can focus on application icons for the moment.  But I think
eventually the other things like backgrounds and gradients will be in the
same package.  So it is likely we want them in the *same* directory tree,
say ${datadir}/wm-images, with subdirectories icons, backgrounds, etc.
 
> links to different sets which have exactly the same files.

Yes, in principle.  Although requiring that an icon exist at all sizes may

> start with only two sizes (standard and mini) and then probably add others.

This sounds reasonable to me.  We seem to already have some "standard" 
sized and "mini" sized icons.  Could we build the first wm-icons package
around these? 

> managers (which are not using imlib or the like). Am I wrong?

I'm glad that someone is checking out what approaches already exist.  I'd
like this to end up being WM-agnostic, so we should be careful to not be
incompatible with others.

I wouldn't want the package to require automatic resizing, but to take
advantage of it if possible.

> > as "14x14/mini.destroy.xpm" in the window manager config file.

Yes, that is a good point.  I like Mikhael's suggestion that we do just
that: refer to icons as "mini/destroy.xpm".  That's pretty close to the
current practice of "mini.destroy.xpm" and shouldn't add too many
directories to the ImagePath.

>   icons/    (different sizes, including standard & mini)

I like this approach, myself.

> or yet better: wm-icons-config --size-sets.

Yes, good!
 
> by wm-icons-config --base-dir or similar.

The hierarchy will end up with more than just icons, so how about
/usr/local/images, with subdirectories icons, backgrounds, etc?

--
Steve Robbins                              <[email-masked]>

If mashed potatoes were security guards, they wouldn't get much done.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 29 Mar 1999 16:42:25 +0300 (IDT)

On Mon, 29 Mar 1999, Steve Robbins wrote:

> OK, we can focus on application icons for the moment.But I think
> same package.So it is likely we want them in the *same* directory tree,

This is also what I suggested. "Different directory tree" ment outside the
icons/ directory. I think wm-icons distribution can be responsible for
icons/, wm-backgrounds for backgrounds/ etc.

> I like this approach, myself.
[...]
> /usr/local/images, with subdirectories icons, backgrounds, etc?

When I wrote this, I thought about icons, backgrounds, decorations inside
/usr/local, but it is configurable. Non-icon images can be included into
wm-icons (wm-images?) only if there are entuthiasts to standardize this
issue.

> This sounds reasonable to me.We seem to already have some "standard" 
> sized and "mini" sized icons.Could we build the first wm-icons package
> around these?

We must create a list of icon names for the common set. I will put my own
list on http://milonka.ml.org/fvwm-icons/ soon, when I'll have free time.
Suggesions are welcome.

This also opens another question. A new standardized icon list, which we
together will hopefully create, will break the existing .fvwm2rc in the
sense that some icons (and at least all mini-icons) will not be accessible
without editing the .rc. Must we still ship the supporting package
fvwm-icons-2.2 for those who want compatibility?

Regards,
Mikhael.

---

From: Pete Forman <[email-masked]>
Date: Tue, 30 Mar 1999 10:28:37 +0100 (BST)

Mikhael Goikhman writes:
 > This also opens another question. A new standardized icon list,
 > which we together will hopefully create, will break the existing
 > .fvwm2rc in the sense that some icons (and at least all mini-icons)
 > will not be accessible without editing the .rc. Must we still ship
 > the supporting package fvwm-icons-2.2 for those who want
 > compatibility?

It should not be too difficult to produce a sed based script to rename 
the icon files in the .rc.  Here's a quick bash at one.

sed -e 's?mini[-.]\([a-zA-Z0-9_.]*\.xpm\)?mini/\1?g' \
    -e 's?\([^/a-zA-Z0-9_.]\)\([a-zA-Z0-9_.]*\.xpm\)?\1std/\2?g' \
    .fvwm2rc > .fvwm2rc.new

Some flavours of sed may prefer parentheses without backslashes.

In any case, there are to be changes with PixmapPath and IconPath
being replaced.
-- 
Pete Forman
Western Geophysical
[email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 30 Mar 1999 17:26:44 +0300 (IDT)

On Tue, 30 Mar 1999, Pete Forman wrote:

> the icon files in the .rc.Here's a quick bash at one.
> 

Good idea.
The script above supposes that the user uses only icons from the fvwm
distribution. Also, icon naming will probably be changed.
Actually, I prefer something like this:

perl -e '$_ = join("", <STDIN>); \
  s!OLD_MINI_ICON_NAME!mini/NEW_CLOSEST_MINI_ICON_NAME!s; \
  ... \
  s!OLD_STD_ICON_NAME!std/NEW_CLOSEST_STD_ICON_NAME!s; \
  ... \
  # changes to (IMAGE|PIXMAP|ICON)PATH
  print $_;
' < .fvwm2rc > .fvwm2rc.new

Also, the old directories icons and icons/mini in (IMAGE|PIXMAP|ICON)PATH
must be deleted and replaced with one new icon base directory.

Regards,
Mikhael.