The icons are now done (attached in a zip).

The following work is needed:
- The icons will need to be put in place, and properly referenced in addon_registry files; and old icons similarly removed. In various cases icons have been moved around or merged, so there will be some work here.
- We have lots of good icons that are technically for tutorials or for our website, that I think we could bundle. People may well find them useful for their own custom menu items. So it would be good to have a file tree more based on what the icons are than what they are used by, and less under images_custom. No need to keep tutorial and website icons logically separated from Composr icons.
- Move menu/_generic_* out of menu directory
- Move some of the _generic_admin icons into a new content_types folder, and remove 'view_' from the filenames
- A lot of things we didn't call icons before, are now exactly like other icons. For example the newscats and calendar type images. So these need moving. Basically most things that are square is now to be classified as an icon.
- Also note cns_rank_images/* are now language-specific and hence need moving under EN somewhere.
- Check to see we haven't missed any icons or that otherwise there aren't .png files that aren't flat-design.
- The Theme Wizard will need to support re-colouring SVG files, probably for most of the icons anyway (needs further thought, once we see how it looks).
- Credits in licence.txt will need to updating, as a lot of old images credit no longer are used.
- The quote_gradient theme image will be changed into a CSS expression (see below).
- Remove psds addon, as we've completely migrated away from this to SVG and don't even need to supply source files.
- We'll probably up the font size on the Composr default theme, so we can get better legibility on our higher-detailed icons (people have bigger screens now, and lots of sites have larger font size).
- Add coding standard for SVG icons.
- We can put all the icons in an all_icons bundled addon AS WELL AS their normal addons. So that people can have them for their custom menu items even if they don't have particular addons installed. And set up a unit test to ensure that is done consistently.
- When all this is implemented, along with some options from #3359, we need to make sure the flat design actually looks *good*. Salman may be in charge of that.


.quote_gradient {
background: #F79523; /* For browsers that do not support gradients */
background: -webkit-linear-gradient(left, #F79523 , #C8691C);
background: -o-linear-gradient(right, #F79523 , #C8691C);
background: -moz-linear-gradient(right, #F79523 , #C8691C);
background: linear-gradient(to right, #F79523 , #C8691C);
height:120px;
width:95%;
}

WIP notes...

Missing .svg versions?
themes/default/images/icons/32x32/filetypes/css.svg
themes/default/images/icons/32x32/filetypes/js.svg
themes/default/images/icons/48x48/buttons/cart_add.svg
themes/default/images/icons/48x48/buttons/cart_checkout.svg
themes/default/images/icons/48x48/buttons/cart_empty.svg
themes/default/images/icons/48x48/buttons/cart_update.svg
themes/default/images/icons/48x48/buttons/cart_view.svg
themes/default/images/icons/48x48/buttons/add_ticket.svg
themes/default/images/icons/48x48/buttons/edit_tree.svg
themes/default/images/icons/28x28/sound_effects.svg
themes/default/images/1x/edited.svg
Handle .txt notes
Add width/height in .tpl's
Add width/height in .css's
Move everything down, no 1x or 28x28 or 32x32 or 48x48
DB update on f_topics icons
Things on tracker issue
Run tests
Test
Mark done
Commit/push

The icons are now integrated and running stably.

I'm keeping this open as there is still some work to do...

Short-term:
- Some further icon changes are now pending, after testing things in practice.

For Salman:
- Icon colours may be considered 'garish' at the moment, or otherwise contrasting poorly against default blue colour. I'm going to pass on to Salman to run with things, and he may choose to recolour many icons as part of his default theme flat-design overhaul.
- We'll probably up the font size on the Composr default theme, so we can get better legibility on our higher-detailed icons (people have bigger screens now, and lots of sites have larger font size). This will be quite a lot of work too.
- Salman may choose to comment out all shadows, gradients, etc, temporarily in the CSS, then we can add them back in as theme options later, testing them only then. That should avoid things getting too complex during redesigning

For Chris (me):
- The Theme Wizard will need to support re-colouring SVG files, potentially - we'll leave this until a bit later.

"Some further icon changes are now pending, after testing things in practice." - this is now done.

We are still tweaking some icons based on how things look in-place.

Here are some general guidelines we will need to apply:
- No light colours that may bleed into a light background surrounding the icon (so some light colours, but they have to be well isolated from the edges)
- Ditto, for dark colours
- Icons that may be shown small (sometimes as little as 14x14) need to be very simple
- It is legitimate to sometimes have multiple versions of icons, e.g. we have delete, delete2, and delete3 - for slightly different conceptions of delete, or different sizes of icon. We should, however, keep them together and use numbering to distinguish. It's not realistic to always expect every icon to work in every size.

Colouring is a bit complex. Colours may be:
- Standard colours we are using (typically light blue, dark blue, orange, and some tinting for shadow [no drop shadow as that's not flat])
- Colours perceived to mean something, esp. red, orange, green.

Colouring is problematic when the Theme Wizard is used. Laying different shades of blue on top of each other sometimes works, but with say orange it would not. I'm not sure there's really any good solution to this if we wish to keep colour. It's mitigated by the Admin Zone running it's own theme at least. Maybe allow users to HSV-shift any individual icon from within the theme image editor. Salman's suggestion is to allow selecting 2 icon colours in the Theme Wizard and us enforcing only 2 core colours in the icons that may run on the main website; that is a possibility too, but wouldn't solve the red/orange/green problem.

The guidelines we go with will need to get written into the coding standards document.

We are now working on black versions of each icon, which will also be included in a font-based icon set.

This will solve the colour problem and give people more flexibility (choice of colourful or any single colour including black and white).

We'll need some kind of convention for how these icons are placed. Maybe an icons_black folder mirroring the icons folder.
We'll need automated testing to make sure that these folders mirror each other perfectly.

Suggestions for implementing single-coloured icons...

Have a symbol, {$IMAGE_COLORISED,url,color} that will provide a colourised version of the given image URL, saving it under uploads/auto_thumbs. This would work for any image.

For an icon, it would look to see if there was an equivalent URL under 'icons_black' rather than 'icons', and look at that. That gives a stronger starting point than our multi-coloured icons.

Then regardless it will change all pixels colours to the given colour (with scaled brightness), save, and provide the URL to that new image.



I like this due to:
- flexibility
- simplicity
- ability to have single-coloured versions even if some addon-maker omits making a black icon
- stops us having to have some complicated scheme for passing around multiple-versions of each theme image through the API or forcing ourselves to always pass theme-image-codes into the templates

"Suggestions for implementing single-coloured icons..."
Salman has implemented a string substitution for the paths in a common template (ICON.tpl). This is also a fine solution.

Finished the final bits needed to finish this / polish it.