Item2456: Make a FamFamFamContrib replacement for System.DocumentGraphics

cos the old graphics are really ugly.

the paths in the FamFamFamGraphics topic are to where the source images are atm, and then I extract them using

cd trunk/FamFamFamContrib/pub/System
cat ../../data/System/FamFamFamGraphics.txt  | grep "^| " | sed "s/.*SYSTEMWEB%\//cp /" | sed "s/ |.*ICON{/ FamFamFamGraphics\//" | sed "s/}.*/.png/" | sed "s/ |.*ICONURL{/ FamFamFamGraphics\//" | grep cp | sh

then I guess I have to convert them to .gif

(atm I have changed the hardcoded .gif to a .png (in Foswiki.pm)

• the left bar icons using FamFamFamGraphics:
  

-- SvenDowideit - 04 Dec 2009

Instead of forcing users to have a white background, I suggest you create 2 FamFamFamGraphics libs: one PNG and one GIF. The GIF version targets older platforms, the PNG version all modern browsers.

-- ArthurClemens - 04 Dec 2009

Is it possible to map the DocumentGraphics identifiers to the famfamfam icon instead of duplicating the icons as attachments to the FramFamFamGraphics topic? All of these icons are already attached to FamFamFamSilkIcons.

-- MichaelDaum - 04 Dec 2009

We have Set ICONTOPIC = %SYSTEMWEB%.DocumentGraphics

-- ArthurClemens - 04 Dec 2009

Yes, its possible to map the identifiers, and thats what I was doing originally (and is why the FamFamFamGraphics topic has mappings) - but I've noticed that its taken me years to get even to this point, and no-one else has even tried, so at this point I'm working on something that will be simple to apply to existing Foswiki's - and thus the duplicates.

post that I'm contemplating either a BuildContrib custom build step to do the copy (so that we don't have to call a script to get the files, slowing everything down), some terrible hard coded rewrite rules, or some kind of on request cache, or, heck more complex css spritage.

-- SvenDowideit - 04 Dec 2009

I don't understand why the ICONTOPIC setting is not sufficient. For existing installations, follow these steps:

1. Download FamFam
2. Install
3. In SitePreferences, write Set ICONTOPIC = ...

-- ArthurClemens - 05 Dec 2009

setting ICONTOPIC is sufficient, but its also a poor mapping - Micha and I keep hoping to have something more maintainable, and more flexible, but given the lack of progress - that is exactly what I'm working on right now.

I've written 2 plugins (over the last 6 years) and various other hacks to the core each an attempt to make this better, but I've disliked each one.

It might be a better idea to make ICONURL{} map to TMPL:P{} and thus use the skin path to over-ride them... - it is after all a skinning/themeing/customisation..

An example of how how poor shows up when you look at the duplication of icons, and non-use of the ICON macro in plugins

I am wondering if we can dump the old icons and replace them with these ones for 1.1 - as they are much prettier..

-- SvenDowideit - 05 Dec 2009

... which is why I'd support adding famfamfam to the distribution.

Two notions:

1. One of the reasons %ICON isn't that useful is that it emits double quotes which disturb parsing the rest of the TML in a lot of cases
2. JQueryPlugin has got a JQICON and JQICONPATH that searches for icons along an {JQueryPlugin]{IconSearchPath} (defaults to FamFamFamSilkIcons, FamFamFamSilkCompanion1Icons, FamFamFamFlagIcons, FamFamFamMiniIcons, FamFamFamMintIcons) There's no attempt in renaming icons in there and therefor no need to create a mapping.

-- MichaelDaum - 07 Dec 2009

mmm, ok, double quotes - I'll fix that, cos its stupid.

wrt jquery, so if you don't do any mapping now for famfamfam, in 5 years when there's a new set of icons, you'll need to do a mapping. basic future eating, meh.

-- SvenDowideit - 07 Dec 2009

Most of the time you decide on one specific icon that matches a specific intent and design. So a mapping might simply be an obstacle rather than of any help.

Icon sets and their names are so very different. None of them really covers all of a mappings abstract names and still pertain an overall consistent look&feel. Either abstract icon names in a mapping are too large or too small. That's why the concept is busted.

Imho, mapping between abstract names and icon sets is not worth the effort to create the mapping. Hopefully interfaces will look differently in 5 years anyway

=> KISS

-- MichaelDaum - 07 Dec 2009

no, this is not KISS

You're looking at this only from the POV of a skin developer, and what we're developing here is a WIKI. one where Users use Icons in their documents.

for that its important that they can use icons which will change rendering to suite later changes of styles.

I care much more for the simplicity and use case of the general user - the advanced skin developers can keep changing things ever 5 years, but the users' content, which they spent hours working on making, is much much more important to seamlessly upgrade.

The work I'm doing here is specifically for them - the ones that 5-10 years ago wrote a management system using the ICON{warning} syntax, and when they upgrade to this icon pack suddenly have a much more attractive system. (not one that looks like an imature mess).

-- SvenDowideit - 14 Dec 2009

Heheh. So users have been waiting 5-10 years to get a slicker interface? That's a drama in itself.

-- MichaelDaum - 14 Dec 2009

Sven. Good point in caring for the general users as first priority.

-- KennethLavrsen - 19 Dec 2009

Great Work, Sven!

I'm missing the led-* icons. I found it out when I was testing trunk with a personal wiki I have... all old icons should be provided to avoid breaking users wikis.

-- GilmarSantosJr - 24 Apr 2010

ah, silly me - spelling mistake I think - it looks like i spelt 'led' as 'bullet'

-- SvenDowideit - 26 Apr 2010

ok, I think I'm done with this.

If anyone finds an issue in this Extension / core, please raise a new Task

-- SvenDowideit - 28 Apr 2010