Yes using font-based icons is interesting (BTW http://fortawesome.github.io/Font-Awesome/icons/ looks richer than http://www.entypo.com/  to me). However, first we need to decide if we wish to support several icon sets or only have one that can potentially be configured. Supporting several icon sets means means introducing a new syntax in XWiki Syntax 2.2. For example: image:icon:<set name>:<icon name> Examples: * image:icon:silk:accept * image:icon:fa:home Now that makes it harder to reference an icon as it means more typing so we could also imagine a configurable mapping (defined in xwiki.properties) as follows: <prefix>.icon.mappings = accept = silk:accept <prefix>.icon.mappings = home = fa:home As a user you’d write: image:icon:accept image:icon:home (technically we’d check the number of “:” after “icon”. If 2 then it’s a named icon set. If 1 then it’s the default mapping) This would have the advantage of allowing mixing icon sets easily without being verbose and with this we would even be able to rewire icons without changing page content (for example image:icon:accept could be rewired from the silk icon set to the fa icon set’s fa:check). Now, we could also decide that we don’t introduce the icon set notation and that we only keep the icon:<icon name> format and that everything has to go through the configurable mapping. Or we could decide that we only ever want one icon set at a time, define properly all the icon names we wish to have and allow configuring the mapping of these name to a an icon set. WDYT? Thanks -Vincent On 24 Apr 2014 at 20:38:04, Sergiu Dumitriu ([email protected]) wrote: +1 for a font-based icon set, but before deciding on a specific one, we should make sure that we have a replacement for all the icons that we're currently using. After a very quick look, it doesn't look like the entypo font covers enough of our needs. Silk doesn't either, to be fair... On 04/24/2014 01:03 PM, Yacine Kebir wrote:

Hello,

i have an idea concerning the icons of base skin colibri or others, we should integrate "Entypo" on the skin ans delete all image icons, the advantage is : 1- we win the chargement time of pages 2- reduce the number of code lines in the code. 3- we can add, edit , put color and change the sise of this icons 4- the skin of this icons are in flat design and we can put it in any form 5- its free for any users for more information http://www.entypo.com/ wordpress have just integrate this solution

Yacine

FWIW - there is another option of creating your own 'xwiki' icon set. We have been using http://fontcustom.com/ with the noun project http://thenounproject.com/ for almost unlimited icon options. regards Andreas Am 28.04.2014 08:46, schrieb [email protected]:

BTW here are some potentially interesting icon packs with lots of icons: http://www.flaticon.com/packs/

Thanks -Vincent

On 24 Apr 2014 at 22:15:59, [email protected] ([email protected]) wrote:

Yes using font-based icons is interesting (BTW http://fortawesome.github.io/Font-Awesome/icons/ looks richer than http://www.entypo.com/ to me).

However, first we need to decide if we wish to support several icon sets or only have one that can potentially be configured.

Supporting several icon sets means means introducing a new syntax in XWiki Syntax 2.2. For example:

image:icon:<set name>:<icon name>

Examples: * image:icon:silk:accept * image:icon:fa:home

Now that makes it harder to reference an icon as it means more typing so we could also imagine a configurable mapping (defined in xwiki.properties) as follows:

<prefix>.icon.mappings = accept = silk:accept <prefix>.icon.mappings = home = fa:home

As a user you’d write: image:icon:accept image:icon:home

(technically we’d check the number of “:” after “icon”. If 2 then it’s a named icon set. If 1 then it’s the default mapping)

This would have the advantage of allowing mixing icon sets easily without being verbose and with this we would even be able to rewire icons without changing page content (for example image:icon:accept could be rewired from the silk icon set to the fa icon set’s fa:check).

Now, we could also decide that we don’t introduce the icon set notation and that we only keep the icon:<icon name> format and that everything has to go through the configurable mapping.

Or we could decide that we only ever want one icon set at a time, define properly all the icon names we wish to have and allow configuring the mapping of these name to a an icon set.

WDYT?

Thanks -Vincent

On 24 Apr 2014 at 20:38:04, Sergiu Dumitriu ([email protected]) wrote:

+1 for a font-based icon set, but before deciding on a specific one, we should make sure that we have a replacement for all the icons that we're currently using. After a very quick look, it doesn't look like the entypo font covers enough of our needs. Silk doesn't either, to be fair...

On 04/24/2014 01:03 PM, Yacine Kebir wrote:

...

Hello,

i have an idea concerning the icons of base skin colibri or others, we should integrate "Entypo" on the skin ans delete all image icons, the advantage is : 1- we win the chargement time of pages 2- reduce the number of code lines in the code. 3- we can add, edit , put color and change the sise of this icons 4- the skin of this icons are in flat design and we can put it in any form 5- its free for any users for more information http://www.entypo.com/ wordpress have just integrate this solution

Yacine

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, So we need to replace all our icons calls with variables. This goes in the direction of Icon Themes where we can easily replace the icons with whatever we want. Not sure how hard is to do this since there are some difference between using font sets and normal image sets (img src, background-image calls will be replaced by CSS classes that uses the font-image). There are a lot of places in our platform/application where we will need to make these changes. I've added all your suggestions on this page http://design.xwiki.org/xwiki/bin/view/Proposal/AppBarIcons A. Glyphicons is nice since is by default provided by Bootstrap. The problem is that it contains a limited number of icons. The current implementation of Flamingo is using Glyphicons icons. B. FontAwesome is really nice since it's on github and provides full access to the icons. Also it is updated and has a decent community. FontAwesome is already used on the design wiki and also there is a macro done by Sergiu. C. Building our own set from free icon packs is also an interesting alternative. The problem is that someone would need to maintain the XWiki custom pack. This solution is good when you want to limit the number of icons you provide, but we as a platform we want to offer a generous offer so we might opt to integrate a more complex set. Still this solution can be used by application developers that don't find a suitable icon in the provide sets. So Glyphicons is already integrated in Flamingo and can be used. We could also vote to integrate FontAwesome to expand our icons poll. I've made an example of icons replacement for the current AppBar view. http://design.xwiki.org/xwiki/bin/view/Proposal/AppBarIcons#HReplacements Thanks, Caty On Tue, Apr 29, 2014 at 10:41 PM, [email protected] <[email protected]> wrote:

On 29 Apr 2014 at 14:08:01, Andreas Hahn ([email protected](mailto: [email protected])) wrote:

...

FWIW - there is another option of creating your own 'xwiki' icon set.

We have been using http://fontcustom.com/ with the noun project http://thenounproject.com/ for almost unlimited icon options.

That looks interesting, thanks for pointing this out!

-Vincent

...

regards Andreas

Am 28.04.2014 08:46, schrieb [email protected]:

...

BTW here are some potentially interesting icon packs with lots of icons: http://www.flaticon.com/packs/

Thanks -Vincent

On 24 Apr 2014 at 22:15:59, [email protected] ([email protected]) wrote:

Yes using font-based icons is interesting (BTW http://fortawesome.github.io/Font-Awesome/icons/ looks richer than http://www.entypo.com/ to me).

However, first we need to decide if we wish to support several icon sets or only have one that can potentially be configured.

Supporting several icon sets means means introducing a new syntax in XWiki Syntax 2.2. For example:

image:icon::

Examples: * image:icon:silk:accept * image:icon:fa:home

Now that makes it harder to reference an icon as it means more typing so we could also imagine a configurable mapping (defined in xwiki.properties) as follows:

.icon.mappings = accept = silk:accept .icon.mappings = home = fa:home

As a user you’d write: image:icon:accept image:icon:home

(technically we’d check the number of “:” after “icon”. If 2 then it’s a named icon set. If 1 then it’s the default mapping)

This would have the advantage of allowing mixing icon sets easily without being verbose and with this we would even be able to rewire icons without changing page content (for example image:icon:accept could be rewired from the silk icon set to the fa icon set’s fa:check).

Now, we could also decide that we don’t introduce the icon set notation and that we only keep the icon: format and that everything has to go through the configurable mapping.

Or we could decide that we only ever want one icon set at a time, define properly all the icon names we wish to have and allow configuring the mapping of these name to a an icon set.

WDYT?

Thanks -Vincent

On 24 Apr 2014 at 20:38:04, Sergiu Dumitriu ([email protected]) wrote:

+1 for a font-based icon set, but before deciding on a specific one, we should make sure that we have a replacement for all the icons that we're currently using. After a very quick look, it doesn't look like the entypo font covers enough of our needs. Silk doesn't either, to be fair...

On 04/24/2014 01:03 PM, Yacine Kebir wrote:

...

Hello,

i have an idea concerning the icons of base skin colibri or others, we should integrate "Entypo" on the skin ans delete all image icons, the advantage is : 1- we win the chargement time of pages 2- reduce the number of code lines in the code. 3- we can add, edit , put color and change the sise of this icons 4- the skin of this icons are in flat design and we can put it in any form 5- its free for any users for more information http://www.entypo.com/ wordpress have just integrate this solution

Yacine

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

2014-06-13 11:03 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:

Hi,

So we need to replace all our icons calls with variables. This goes in the direction of Icon Themes where we can easily replace the icons with whatever we want. Not sure how hard is to do this since there are some difference between using font sets and normal image sets (img src, background-image calls will be replaced by CSS classes that uses the font-image). There are a lot of places in our platform/application where we will need to make these changes.

I've added all your suggestions on this page http://design.xwiki.org/xwiki/bin/view/Proposal/AppBarIcons

A. Glyphicons is nice since is by default provided by Bootstrap. The problem is that it contains a limited number of icons. The current implementation of Flamingo is using Glyphicons icons.

B. FontAwesome is really nice since it's on github and provides full access to the icons. Also it is updated and has a decent community. FontAwesome is already used on the design wiki and also there is a macro done by Sergiu.

C. Building our own set from free icon packs is also an interesting alternative. The problem is that someone would need to maintain the XWiki custom pack. This solution is good when you want to limit the number of icons you provide, but we as a platform we want to offer a generous offer so we might opt to integrate a more complex set. Still this solution can be used by application developers that don't find a suitable icon in the provide sets.

So Glyphicons is already integrated in Flamingo and can be used. We could also vote to integrate FontAwesome to expand our icons poll. I've made an example of icons replacement for the current AppBar view. http://design.xwiki.org/xwiki/bin/view/Proposal/AppBarIcons#HReplacements

To me it's noticeable, that when used in 16x16px, FontAwesome monochromic icons are not striking at all. I also tried them for some menu I did, and it's nice looking, but difficult to find quickly what they represent. When comparing to silk as in your table, well, I tend to prefer silk :) But maybe that can be improved by using differerent colors - but it improves only some of them (like, rss feed orange, + sign green, etc). But in greater size (like you show for AppBar), this problem disappears.

Thanks, Caty

On Tue, Apr 29, 2014 at 10:41 PM, [email protected] <[email protected]> wrote:

...

On 29 Apr 2014 at 14:08:01, Andreas Hahn ([email protected](mailto: [email protected])) wrote:

...

FWIW - there is another option of creating your own 'xwiki' icon set.

We have been using http://fontcustom.com/ with the noun project http://thenounproject.com/ for almost unlimited icon options.

That looks interesting, thanks for pointing this out!

-Vincent

...

regards Andreas

Am 28.04.2014 08:46, schrieb [email protected]:

...

BTW here are some potentially interesting icon packs with lots of icons: http://www.flaticon.com/packs/

Thanks -Vincent

On 24 Apr 2014 at 22:15:59, [email protected] ([email protected]) wrote:

Yes using font-based icons is interesting (BTW http://fortawesome.github.io/Font-Awesome/icons/ looks richer than http://www.entypo.com/ to me).

However, first we need to decide if we wish to support several icon sets or only have one that can potentially be configured.

Supporting several icon sets means means introducing a new syntax in XWiki Syntax 2.2. For example:

image:icon::

Examples: * image:icon:silk:accept * image:icon:fa:home

Now that makes it harder to reference an icon as it means more typing so we could also imagine a configurable mapping (defined in xwiki.properties) as follows:

.icon.mappings = accept = silk:accept .icon.mappings = home = fa:home

As a user you’d write: image:icon:accept image:icon:home

(technically we’d check the number of “:” after “icon”. If 2 then

it’s

...

a named icon set. If 1 then it’s the default mapping)

...

...

This would have the advantage of allowing mixing icon sets easily

without being verbose and with this we would even be able to rewire icons without changing page content (for example image:icon:accept could be rewired from the silk icon set to the fa icon set’s fa:check).

...

Now, we could also decide that we don’t introduce the icon set

notation and that we only keep the icon: format and that everything has to go through the configurable mapping.

...

Or we could decide that we only ever want one icon set at a time,

define properly all the icon names we wish to have and allow configuring the mapping of these name to a an icon set.

...

WDYT?

Thanks -Vincent

On 24 Apr 2014 at 20:38:04, Sergiu Dumitriu ([email protected])

wrote:

...

+1 for a font-based icon set, but before deciding on a specific one,

we

...

should make sure that we have a replacement for all the icons that we're currently using. After a very quick look, it doesn't look like the entypo font covers enough of our needs. Silk doesn't either, to be fair...

On 04/24/2014 01:03 PM, Yacine Kebir wrote:

...

Hello,

i have an idea concerning the icons of base skin colibri or others, we should integrate "Entypo" on the skin ans delete all image icons, the advantage is : 1- we win the chargement time of pages 2- reduce the number of code lines in the code. 3- we can add, edit , put color and change the sise of this icons 4- the skin of this icons are in flat design and we can put it in any form 5- its free for any users for more information http://www.entypo.com/ wordpress have just integrate this solution

Yacine

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Thu, Jul 10, 2014 at 1:25 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

2014-04-24 22:15 GMT+02:00 [email protected] <[email protected]>:

...

Yes using font-based icons is interesting (BTW http://fortawesome.github.io/Font-Awesome/icons/ looks richer than http://www.entypo.com/ to me).

However, first we need to decide if we wish to support several icon sets or only have one that can potentially be configured.

Supporting several icon sets means means introducing a new syntax in XWiki Syntax 2.2. For example:

image:icon:<set name>:<icon name>

Examples: * image:icon:silk:accept * image:icon:fa:home

Now that makes it harder to reference an icon as it means more typing so we could also imagine a configurable mapping (defined in xwiki.properties) as follows:

<prefix>.icon.mappings = accept = silk:accept <prefix>.icon.mappings = home = fa:home

As a user you’d write: image:icon:accept image:icon:home

(technically we’d check the number of “:” after “icon”. If 2 then it’s a named icon set. If 1 then it’s the default mapping)

This would have the advantage of allowing mixing icon sets easily without being verbose and with this we would even be able to rewire icons without changing page content (for example image:icon:accept could be rewired from the silk icon set to the fa icon set’s fa:check).

Now, we could also decide that we don’t introduce the icon set notation and that we only keep the icon:<icon name> format and that everything has to go through the configurable mapping.

Or we could decide that we only ever want one icon set at a time, define properly all the icon names we wish to have and allow configuring the mapping of these name to a an icon set.

Or... it could even depends on the skin. Colibri uses silk and Flamingo font-based icons.

IMO this can only be done by using Icon Themes, see http://jira.xwiki.org/browse/XWIKI-8501 We replace everywhere the usage by variables, like '$theme.icon.page' .actionmenu .tmPage { background-image: $theme.icon.page; } where #set($discard = $themeI.put('icon.page', "url($xwiki.getSkinFile('icons/silk/page_white_text.gif'))")) etc. This is the case when we have images inserted with background-image. In case of font icons, we can have something like <div class="icon icon-page"></div> where if the IconTheme is set to Font Awesome we have .icon:extend(.fa all) {} .icon-search:extend(.fa-search all) {} or if the IconTheme is set to Glyphicons we have .icon:extend(.glyphicon all) {} .icon-search:extend(.glyphicon-search all) {} We will need to modify some calls and someone needs to investigate a bit what we use. Related to icons there are some very old investigations that can be found here http://design.xwiki.org/xwiki/bin/view/Standards/IconsStudy http://platform.xwiki.org/xwiki/bin/view/DevGuide/StandardIconClasses http://design.xwiki.org/xwiki/bin/view/Standards/Icons Thanks, Caty

...

WDYT?

Thanks -Vincent

On 24 Apr 2014 at 20:38:04, Sergiu Dumitriu ([email protected]) wrote:

+1 for a font-based icon set, but before deciding on a specific one, we should make sure that we have a replacement for all the icons that we're currently using. After a very quick look, it doesn't look like the entypo font covers enough of our needs. Silk doesn't either, to be

fair...

...

On 04/24/2014 01:03 PM, Yacine Kebir wrote:

...

Hello,

i have an idea concerning the icons of base skin colibri or others, we should integrate "Entypo" on the skin ans delete all image icons, the advantage is : 1- we win the chargement time of pages 2- reduce the number of code lines in the code. 3- we can add, edit , put color and change the sise of this icons 4- the skin of this icons are in flat design and we can put it in any form 5- its free for any users for more information http://www.entypo.com/ wordpress have just integrate this solution

Yacine

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

For the size of the icon, we can have something like BS is providing for input or buttons size '.lg' for large or '.sm' for small, like '.icon .icon-search .icon-lg'. An interesting option would be to have a responsive or adaptable size that takes the size of the container (width: 100%). It could be a solution for the AppBar for example for the icons to change dimension depending on the media query. Thanks, Caty On Thu, Jul 10, 2014 at 3:08 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

Just a note, although 'icon icon-page' might be very semantic as names, I'm sure .glyphicon and .fa used this naming convention in order not to conflict with the very generic 'icon' name. We can select something more particular too. It reduces the semantic meaning, and maybe it will add some lenght to the class name, but at least we get more error-proof.

Thanks, Caty

On Thu, Jul 10, 2014 at 2:59 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

On Thu, Jul 10, 2014 at 1:25 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2014-04-24 22:15 GMT+02:00 [email protected] <[email protected]>:

...

Yes using font-based icons is interesting (BTW http://fortawesome.github.io/Font-Awesome/icons/ looks richer than http://www.entypo.com/ to me).

However, first we need to decide if we wish to support several icon sets or only have one that can potentially be configured.

Supporting several icon sets means means introducing a new syntax in XWiki Syntax 2.2. For example:

image:icon:<set name>:<icon name>

Examples: * image:icon:silk:accept * image:icon:fa:home

Now that makes it harder to reference an icon as it means more typing so we could also imagine a configurable mapping (defined in xwiki.properties) as follows:

<prefix>.icon.mappings = accept = silk:accept <prefix>.icon.mappings = home = fa:home

As a user you’d write: image:icon:accept image:icon:home

(technically we’d check the number of “:” after “icon”. If 2 then it’s a named icon set. If 1 then it’s the default mapping)

This would have the advantage of allowing mixing icon sets easily without being verbose and with this we would even be able to rewire icons without changing page content (for example image:icon:accept could be rewired from the silk icon set to the fa icon set’s fa:check).

Now, we could also decide that we don’t introduce the icon set notation and that we only keep the icon:<icon name> format and that everything has to go through the configurable mapping.

Or we could decide that we only ever want one icon set at a time, define properly all the icon names we wish to have and allow configuring the mapping of these name to a an icon set.

Or... it could even depends on the skin. Colibri uses silk and Flamingo font-based icons.

IMO this can only be done by using Icon Themes, see http://jira.xwiki.org/browse/XWIKI-8501

We replace everywhere the usage by variables, like '$theme.icon.page' .actionmenu .tmPage { background-image: $theme.icon.page; } where #set($discard = $themeI.put('icon.page', "url($xwiki.getSkinFile('icons/silk/page_white_text.gif'))")) etc. This is the case when we have images inserted with background-image.

In case of font icons, we can have something like <div class="icon icon-page"></div>

where if the IconTheme is set to Font Awesome we have .icon:extend(.fa all) {} .icon-search:extend(.fa-search all) {}

or if the IconTheme is set to Glyphicons we have .icon:extend(.glyphicon all) {} .icon-search:extend(.glyphicon-search all) {}

We will need to modify some calls and someone needs to investigate a bit what we use.

Related to icons there are some very old investigations that can be found here http://design.xwiki.org/xwiki/bin/view/Standards/IconsStudy http://platform.xwiki.org/xwiki/bin/view/DevGuide/StandardIconClasses http://design.xwiki.org/xwiki/bin/view/Standards/Icons

Thanks, Caty

...

...

WDYT?

Thanks -Vincent

On 24 Apr 2014 at 20:38:04, Sergiu Dumitriu ([email protected]) wrote:

+1 for a font-based icon set, but before deciding on a specific one, we should make sure that we have a replacement for all the icons that

we're

...

currently using. After a very quick look, it doesn't look like the entypo font covers enough of our needs. Silk doesn't either, to be fair...

On 04/24/2014 01:03 PM, Yacine Kebir wrote:

...

Hello,

i have an idea concerning the icons of base skin colibri or others, we should integrate "Entypo" on the skin ans delete all image icons, the advantage is : 1- we win the chargement time of pages 2- reduce the number of code lines in the code. 3- we can add, edit , put color and change the sise of this icons 4- the skin of this icons are in flat design and we can put it in any form 5- its free for any users for more information http://www.entypo.com/ wordpress have just integrate this solution

Yacine

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs