2014-06-13 11:03 GMT+02:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>om>:
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, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 29 Apr 2014 at 14:08:01, Andreas Hahn (ahahn(a)gmx.net(mailto:
ahahn(a)gmx.net)) 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 vincent(a)massol.net:
> 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, vincent(a)massol.net (vincent(a)massol.net)
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 (sergiu(a)xwiki.com)
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs