Feature Proposal: Add FamFamFamContrib to the Core

Motivation

the 10 year old hand created DocumentGraphics really looks dated, and does not suit our image.

The FamFamFam icons are a very good example of high utility attractive icons, and with the addition of the 2 companion packs, cater to a large proportion of our needs.

In the last weeks, I have been working on adding a replacement mapping for the legacy DocumentGraphics, which we can use to help transitions

Description and Documentation

Additionally to adding FamFamFamContrib to the core, I'd like to add support for the other Icons attached to other topics.

To give us a better extensibility&replaceablility, I will modify the ICONTOPIC setting to be a list of web.topics, and then make ICON follow that list in order, until it finds a suitable file in the pub dir's thereof. That way the icons in famfamfam can be over-ridden locally by prepending a local topic to the list.

Ideally it would be nice to provide a skin mapping for icons used, but this may well be much more complex than we have time/energy for...

Don't forget to upgrade SmiliesPlugin too

Examples

see http://foswiki.org/Tasks/Item2456 for a little taster..

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: SvenDowideit - 14 Dec 2009

Discussion

Yes please! We would also need that for MenuItemsForTopicInteraction

-- CarloSchulz - 14 Dec 2009

Me too a yes please! However, I think that the recent work on Tasks.Item2456 needs to be reconsidered before as it duplicates the same icons for different purposes.

-- MichaelDaum - 14 Dec 2009

+1, I agree about the image, though I don't agree that the DocumentGraphics are particularly dated; much of the artwork there is quite good.

It would be nice to have a process for extending the FamFamFamContrib, too, as the original source of these icons seems to be frozen.

-- CrawfordCurrie - 14 Dec 2009

there is sort of a process for extending the icons - that's what the 1 companion sets (the second was created last month..) are, and then I created some more as FamFamFamFoswikiExtra's

but wrt extending them in foswiki, I will be looking at changing from 'ICONTOPIC' a comma separated list of topics (added to proposal)

I do still wonder if we can implement the ICON macro using either TMPL:DEF's or even transform them into =span='s with css to the images, so that they can be trivially skinned - especially the mappings from abstract name to real icon..

-- SvenDowideit - 14 Dec 2009

I like the second idea (css spans) best.

-- CrawfordCurrie - 14 Dec 2009

Me too. That's what I did for JQICON in JQueryPlugin. Btw. I'd be even more happy if %ICON would also allow to use the native fam fam fam icon names instead of some mapping.

Nother point. How about moving the old DocumentGraphics to the TWikiCompatibilityPlugin?

-- MichaelDaum - 15 Dec 2009

I am not sure what the implication of moving DocumentGraphics to TWikiCompatibilityPlugin. Would I then need TWikiCompatibilityPlugin if I have used the standard ICONs? In that case my reaction is a big no. We are now a 1 year old project and the icon legacy is not just TWiki but also our own 1 year of existance.

We should not force anything to use TWikiCompatibilityPlugin to get the icons we have shipped for a year under Foswiki context. I have personally disabled TWikiCompatibilityPlugin on my production sites now after having detoxed them. And we must assume new Foswiki installations has it disabled too.

But maybe I misunderstand.

Sven - I am not sure what we are deciding for here.

I assume you are not proposing to add the FamFamFamContrib as the contrib it is today but instead update the existing icon set? Or do I totally misunderstand.

It is essential that we continue to have all the existing - OR EQUIVALENT in same size and filename - in DocumentGraphics. When I upgraded from TWiki to Foswiki it took a long time before I had eliminated the last hardcoded TWikiDocGraphics that users had added everywhere. Many have not used the ICON macro but have used all sorts of ways to include the graphics in their pages.

As long as we can keep path names and sizes same I am OK with modernizing the icons to match also new skins etc when you use the ICON macro.

I have raised concern but hope to happily remove it when I have gotten my uncertainties of the actual proposal details clarified.

-- KennethLavrsen - 19 Dec 2009

I want to do both - update the DocumentGraphics attachments with same size same name icons, and add the large number of extra icons to our base. Michael's idea of shifting the old DocumentGraphics to the TWiki web is a good one - it would be there only for people that want their foswiki to look as much like TWiki as possible - whereas the default would look new and pretty

so yes, my intentions align completely with yours

-- SvenDowideit

As long as I can run with TWikiCompatibilityPlugin disabled and my DocumentGraphics links still work but with improved equivalent icons my concern is removed. I have removed my name from the concern field. Thanks Sven.

-- KennethLavrsen - 20 Dec 2009

first spike of work for this is

1. move System.DocumentGraphics into the TWikiCompatibilityContrib as System.OriginalDocumentGraphics topic - in case there are users that need / prefer that look
2. move System.FamFamFamGraphics to System.DocumentGraphics thus making those icons the full replacement for the old
3. add FamFamFamContrib to the code MANIFEST - TODO have to reconsider this portion of the proposal - this will add 3MB of images to the release - 1.0.9's release is about 5MB atm...
4. set ICONTOPIC to the legacy compatible FamFamFamGraphics topic (for ICONURL and ICONURLPATH)
5. add icons.tmpl and code to ICON so that skins can be used to over-ride icons - define a few or the simplistic 'icons' using html and css
   • added tmpl entries for the non-16px icons
   • TODO merge over the new icon entries and find/make FamFamFam versions

you can see the new look on the trunk test system

-- SvenDowideit - 20 Mar 2010, 21 Mar 2010

move System.DocumentGraphics into the TWikiCompatibilityContrib ????? No dammit No. We with production sites have plenty of hardcoded links everywhere linking to DocumentGraphics.

And I want that to work. And I do not run with the compatibility plugin anymore. I do not want that overhead. There is no sain reason to rename the topic or move it around, What is wrong with the current name?

This is exactly what I raised concern against and what you assured you would not do

-- KennethLavrsen - 20 Mar 2010

yes, um, and no.

your outburst has convinced me that yes, I need to do the first bulletpoint in 1)

• • TODO I think I actually should rename it too, so that any hardcoded references to the topic will automatically get the new icons set too

and so I will leave the old System.DocumentGraphics in TWikiCompatibilityContrib, but rename it to System.OriginalDocumentGraphics and then rename the System.FamFamFamGraphics to System.DocumentGraphics.

Which is, as the _TODO points out, specifically to update the existing hardcoded links to the new icons.

However, considering that TWikiCompatibilityContrib is currently in the release, and that thus the move does not change the foswiki 1.1 release in any way - its currently no noticeable change for you. (And no, to get to the moved System.DocumentGraphics, you do not need to run the compatibility plugin.

-- SvenDowideit - 20 Mar 2010

As long as any icon URL pointing directly to System.DocumentGraphics still work and still give an icon with the same meaning as it does in 1.0.X then I am happy. I have no problem with refreshing the design of the icons to something new. I just don't want broken links all over when people have used direct links to graphics.

That is all I ask for. I am perfectly OK with the old icons getting a refresh. I do not even see the need to move the old to System.OriginalDocumentGraphics. Who would use some icons hidden there? You just need to make sure there is a 1:1 match between the old and the new and that they fit in size.

The reason I am so kean on this is that I had quite many hours of work changing TWikiDocGraphics links to DocumentGraphics when I upgraded to Foswiki so I know I have around 500-600 direct links that the users have used everywhere to put small icons in their topics.

-- KennethLavrsen - 20 Mar 2010

FamFamFamGraphics topic has now been renamed to DocumentGraphics - we ship the old icons in the core via the TWikiCompat in case some users need that look

also added the non-16px icons to the icons.tmpl file, so users are no longer asked to write the rather insane: <img src="%ICONURL{more-small}%" width="13" height="13" alt="Read more" border="0" /> , %ICON{more-small}% will do it for them (the ICONURL method continues to work).

-- SvenDowideit - 21 Mar 2010

Another reminder.

It is the entire path to the graphics people use when they use icons everywhere. People do not generally use ICON no matter how much you try to teach them. I personally have users in China, Malaysia, Poland, UK, Germany, USA, and Denmark. I cannot walk around and teach them all. The users use the feature that you can write a URL to a jpg, gif, or png and it is shown.

I bet my users are not unique. All Foswiki installations will have a similar pattern.

Foswiki is a 1.5 year old project now and saying that people can just use TWiki Compatibility is no longer a valid way to see this. People that never used TWiki but started with Foswiki are also facing this situation. The TCP adds an overhead that we all have worked hard to get rid of and new Foswiki users should not have to drag along.

All icons that were in DocumentGraphics must have an equivalent after you have updated them. And the filename must be the same incl the extension.

Ie. if the replacement is a png and the old was a gif we still have the same issue.

I fear we are steering straight into a disaster here and I am not sure people realize what it is you are doing Sven.

If I understand things right now - people will end up with broken images all over the place and a heck of a search and replace effort to replace .gif with .png. It will be hell to upgrade from 1.0 to 1.1 for no really good reason.

-- KennethLavrsen - 21 Mar 2010

I just noticed that the DocumentGraphics pub directory on trunk currently contains all icons in both gif and png.

That is a solution to my concern. If you keep the gifs there the problem is solved. And it is perfectly OK the gifs are copies of the new png files from FamFamFam. It is broken icon links I am concerned about. Not the looks.

You haven't written anywhere above that this was your plan. But if this is your plan it is a good plan.

-- KennethLavrsen - 21 Mar 2010

I like the new icons a lot.

-- MartinSeibert - 21 Mar 2010

to quote the original spec In the last weeks, I have been working on adding a replacement mapping for the legacy DocumentGraphics, which we can use to help transitions.

Please find and raise issues that actually exist - the one you've shouted about repeatedly in this topic has never existed, stop taking up time with incorrect FUD.

Later: having had a full day of looking after girls to ponder this topic's history, I wonder if its all down to a difference in core belief. When you get right down to it, I strongly believe that no feature request should be allowed to break backwards compatibility unless this was agreed to and well documented in the specification. The corollary of this (and applies in this feature) is that I make every effort to make things compatible, but know that there are legacy effects I don't know, and thus expect tasks to be raised when someone finds something that I did unintentionally break. In this specific feature, Its most likely to be that I'm missing an image (there are about 80 more of them compared to the other project), and will be pretty simple to rectify, whereas in the really major SEARCH work I've been working on, I expect to get told about alot of difficult issues :(.

-- SvenDowideit - 22 Mar 2010

I read In the last weeks, I have been working on adding a replacement mapping for the legacy DocumentGraphics, which we can use to help transitions as being the work of creating a topic in TWikiCompatibilityPlugin. I did not know that the icons also existed as gifs in the FamFamFam replacement. If you had put that detail I would have understood. FUD comes from having to guess and guessing wrong.

-- KennethLavrsen - 22 Mar 2010