Bring images under source control

[GoogleCodeExporter]

I suggest we get the images under source control instead of as zip files on the 
wiki.  That way users will be able to check out the images and easily keep up 
to date with additions instead of manually downloading and unzipping the images 
for each release.

Original issue reported on code.google.com by stefanb...@gmail.com on 18 Feb 2011 at 3:15

[GoogleCodeExporter]

Not to say we shouldn't also make it available as a zip file too...

Original comment by stefanb...@gmail.com on 18 Feb 2011 at 3:17

[GoogleCodeExporter]

- Checked images in using the following directory structure:

flag
flag/gif
flag/png
mini
mini/gif
silk
silk/gif
silk/png

- Capitalized readme filenames.
- Edited image paths in silk's README.html.

You can browse the directory tree here:
http://code.google.com/p/famfamfam/source/browse/

Original comment by stefanb...@gmail.com on 18 Feb 2011 at 4:34

[GoogleCodeExporter]

The README.html being created automatically, so I'll have to change some stuff 
in the script instead of directly in the file.

I believe zip-files are much easier to use, especially for people who doesn't 
know about version control. They are also created automatically, so it's not 
really a problem keeping them.

Maybe it would also be a good idea to keep only the real silk-icons in it's own 
directory and then create directories with additional sets.

Original comment by janpol...@gmail.com on 18 Feb 2011 at 9:41

• Added labels: Priority-Medium, Type-Other
• Removed labels: Priority-High, Type-Enhancement

[GoogleCodeExporter]

I thought about keeping the images grouped by contributor, but if we end up 
with more contributors (we're already up to 4), then the actual users of the 
icons will have to hunt for icons in multiple directories.  I suggested in 
Issue 5 that we include a file that lists who contributed which icon.  I was 
also thinking of improving on the README.html so it would also have this 
metadata.  Does this seem like a good solution?

Original comment by stefanb...@gmail.com on 18 Feb 2011 at 2:20

[GoogleCodeExporter]

Actually... I don't even like the way the README.html file is right now, 
because it loads every single one of the silk icons. With an increasing number 
of icons coming, it will only take longer to load. So splitting up the icons 
one way or the other would be a good idea.

Creating a script that automatically creates the necessary .html and .wiki 
files is IMHO the best solution (compared to a file with just the icon name and 
name of contributor), because it simply does give a much better overview of the 
icons.

I can look into it when the new sets of icons are in place?

Regarding the structure of the icons, then it seems more logical to me, that 
they are grouped by "name" - i.e.: flag, silk, companion_pack_1 and 
companion_pack_2, faded (?), redish (?)... Or I can just name my 
"contributions" companion_pack_3 :).

Original comment by janpol...@gmail.com on 18 Feb 2011 at 11:42

[GoogleCodeExporter]

I would worry that by breaking up a consistent set of icons into "packs", it 
would make finding icons difficult for users.  They'd have to open the "silk" 
folder, look around, not find what they're looking for, then open up 
"companion_pack_1", look around, etc.  I would think they'd want all the icons 
of a consistent set together.

Also, I'm only contributing 5 new icons for now, which I don't consider worthy 
of the title "companion pack" or worthy of its own directory.  If I decide to 
add one or two more, then I can just add them without waiting to accumulate 
them into a "pack".

The README.html I was envisioning would have a javascript list/array/object 
with all the metadata about all the images, and contain a file browser with 
pagination, so they could quickly and dynamically narrow their search by file 
name, contributor, set/pack name, etc.  How this would translate to the wiki 
page is something I've yet to determine and am open to suggestions...

Original comment by stefanb...@gmail.com on 21 Feb 2011 at 6:43

[GoogleCodeExporter]

IMHO there are way too many icons already (especially with the faded and red 
icons), so loading a page a with all icons is very heavy. It could be a 
solution to create a big mosaic of all the icons though.

Because of the amount of icons I believe that grouping the icons into packs is 
not that bad an idea.

With the index.php file from the old repository it was possible to search the 
whole icon directory for specific search patterns.

Original comment by janpol...@gmail.com on 21 Feb 2011 at 9:29

[GoogleCodeExporter]

I could see grouping them by subject/theme or color, but not really by the 
original packs they came in--it just doesn't make sense for the user.  I 
personally don't mind browsing the list of 1000 or so icons on my local 
filesystem, but I agree the wiki and readme pages are getting unwieldy.

I also agree a mosaic image is a good idea.  Looks like ImageMagick's "montage" 
command would do what we want.  I might play around with it tonight:
http://www.imagemagick.org/Usage/montage/

I still think a Javascript solution might be a good addition, because then 
they'd have an icon browser built-in to the release.  Something like this 
(except it wouldn't load every image when the page loads, only the first 50 or 
so):
http://tdg-i.com/js/examples/ext/tdgiux/TDGi.iconMgr/

Original comment by stefanb...@gmail.com on 21 Feb 2011 at 10:49

[GoogleCodeExporter]

So a "theme" like regular, faded, redish and maybe more? That's fine with me. 
Those directories would also be easy to keep updated, as it's just a script 
command that needs to be executed.

IM's motage will indeed do the job i.e.: "montage *.png -geometry +3+3 
_montage.png"

The index.php is a PHP and Javascript that does the exact same thing as your 
link. The disavantage is of course, that you need a PHP-server in order to see 
the script.

A plain HTML/Javascript file on the other hand will become *huge* with 1K+ 
image tags, but maybe it's doable.

Original comment by janpol...@gmail.com on 21 Feb 2011 at 11:22