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
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
- move
System.DocumentGraphics
into the TWikiCompatibilityContrib as System.OriginalDocumentGraphics
topic - in case there are users that need / prefer that look
- move
System.FamFamFamGraphics
to System.DocumentGraphics
thus making those icons the full replacement for the old
- 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...
- set ICONTOPIC to the legacy compatible FamFamFamGraphics topic (for ICONURL and ICONURLPATH)
- 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