Silk icon set for Gnus and synchronizing it into Emacs

Silk icon set for Gnus and synchronizing it into Emacs

[Ted Zlatanov]

For Gnus I'd like to bring in the Silk icon set and the related flags
icons from http://www.famfamfam.com/lab/icons/flags/ (the flags are
completely free without attribution).  This is to serve together with
Gnome icon sets as defined by
http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
to present some aspects of the Gnus UI better.  The goal is to use the
best available icon, subject to the user's preferences, especially on
platforms where Gnome icon themes are not available.

According to http://www.famfamfam.com/lab/icons/silk/ the Silk icon set
is licensed under http://creativecommons.org/licenses/by/3.0/ and
attribution is needed.  Would it be OK to include it in Gnus *and* Emacs
or should it live in Gnus only?  I'll make sure the attribution is done
either way but want to make sure there are no objections to
synchronizing Silk into Emacs.

Thanks
Ted

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Ted Zlatanov]

On Mon, 21 Mar 2011 15:43:19 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> For Gnus I'd like to bring in the Silk icon set and the related flags
TZ> icons from http://www.famfamfam.com/lab/icons/flags/ (the flags are
TZ> completely free without attribution).  This is to serve together with
TZ> Gnome icon sets as defined by
TZ> http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
TZ> to present some aspects of the Gnus UI better.  The goal is to use the
TZ> best available icon, subject to the user's preferences, especially on
TZ> platforms where Gnome icon themes are not available.

TZ> According to http://www.famfamfam.com/lab/icons/silk/ the Silk icon set
TZ> is licensed under http://creativecommons.org/licenses/by/3.0/ and
TZ> attribution is needed.  Would it be OK to include it in Gnus *and* Emacs
TZ> or should it live in Gnus only?  I'll make sure the attribution is done
TZ> either way but want to make sure there are no objections to
TZ> synchronizing Silk into Emacs.

OK, can anyone at least tell me if adding something with the Creative
Commons 3.0 license to Emacs is acceptable?

Thanks
Ted

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Mon, 21 Mar 2011 15:43:19 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote:
>
> TZ> For Gnus I'd like to bring in the Silk icon set... This is to
> TZ> serve together with Gnome icon sets... The goal is to use the best
> TZ> available icon, subject to the user's preferences, especially on
> TZ> platforms where Gnome icon themes are not available.

Do you have any specific icons in mind, that are not present in the
Gnome icon set?  License aside (see below), I am leery of this move:

1. The Silk icon set is 700 files.  Adding 700 files to the Emacs
   distribution, just because some of these might be used by Emacs
   libraries at some point, is unreasonable..

2. The right approach is to use system icons whenever possible.
   Rather than adding icon files in support where the x-gtk-stock-map
   functionality doesn't exist, it's better to improve those platforms
   by implementing facilities analogous to x-gtk-stock-map.

> OK, can anyone at least tell me if adding something with the Creative
> Commons 3.0 license to Emacs is acceptable?

Let's discuss this off-list.

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Ted Zlatanov]

On Wed, 23 Mar 2011 13:51:44 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Mon, 21 Mar 2011 15:43:19 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote:
>> 
TZ> For Gnus I'd like to bring in the Silk icon set... This is to
TZ> serve together with Gnome icon sets... The goal is to use the best
TZ> available icon, subject to the user's preferences, especially on
TZ> platforms where Gnome icon themes are not available.

CY> Do you have any specific icons in mind, that are not present in the
CY> Gnome icon set?

There's two issues.  One, Gnome themes are meant for system appearance,
NOT for applications (although applications can use them).  I think the
Silk-only *names* are worth including for their semantic meaning,
e.g. "css_valid" which Gnome themes don't have (they go by MIME type but
can't combine that with the "valid" meaning).  This is not a shortcoming
of the Gnome themes, they just don't cover the same territory that Silk
does.

Two, the standard Gnome icons are pretty comprehensive, looking at
http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html,
but they require Gnome.  I think we can do better when Gnome is not
installed or available.

CY> License aside (see below), I am leery of this move:

CY> 1. The Silk icon set is 700 files.  Adding 700 files to the Emacs
CY>    distribution, just because some of these might be used by Emacs
CY>    libraries at some point, is unreasonable..

We could add them as a tar file or a single image that can be then cut
up or indexed into, like
http://www.famfamfam.com/lab/icons/silk/previews/index_abc.png.  A
reliable, always available set of semantically meaningful and easily
recognizable icons would be a very good thing.  Right now Emacs doesn't
have that on non-Gnome platforms.

I think applications will start using the Silk icons very quickly if
they are provided.  That's just my opinion, of course, but at least for
Gnus we plan to do so.

Would it be acceptable to make Silk an ELPA package?  That seems like a
cleaner solution...

CY> 2. The right approach is to use system icons whenever possible.

I disagree.  The system icons are not sufficient to represent
application functionality.  When we try to force applications to use
just the system icons we end up with bad UI results.  Compare Silk's
icons to the Gnome standard icons and you'll see they both have
advantages.

CY>    Rather than adding icon files in support where the x-gtk-stock-map
CY>    functionality doesn't exist, it's better to improve those platforms
CY>    by implementing facilities analogous to x-gtk-stock-map.

Sorry, I don't understand.  You're saying we should improve W32 and Mac
OS X and Solaris, etc.?

Ted

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Wed, Mar 23 2011, Ted Zlatanov wrote:

> There's two issues.  One, Gnome themes are meant for system appearance,
> NOT for applications (although applications can use them).  I think the
> Silk-only *names* are worth including for their semantic meaning,
> e.g. "css_valid" which Gnome themes don't have (they go by MIME type but
> can't combine that with the "valid" meaning).  This is not a shortcoming
> of the Gnome themes, they just don't cover the same territory that Silk
> does.

I think this is partially wrong. Nautilus supports combining icons by
adding an "emblem" on top of them. Therefore you can add a "valid
emblem" on top of a "CSS icon". See gvfs-set-attribute.

Just to say.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Ted Zlatanov]

On Thu, 24 Mar 2011 10:42:18 +0100 Julien Danjou <julien@danjou.info> wrote: 

JD> On Wed, Mar 23 2011, Ted Zlatanov wrote:
>> There's two issues.  One, Gnome themes are meant for system appearance,
>> NOT for applications (although applications can use them).  I think the
>> Silk-only *names* are worth including for their semantic meaning,
>> e.g. "css_valid" which Gnome themes don't have (they go by MIME type but
>> can't combine that with the "valid" meaning).  This is not a shortcoming
>> of the Gnome themes, they just don't cover the same territory that Silk
>> does.

JD> I think this is partially wrong. Nautilus supports combining icons by
JD> adding an "emblem" on top of them. Therefore you can add a "valid
JD> emblem" on top of a "CSS icon". See gvfs-set-attribute.

Sorry, I don't know how that would help inside Emacs or Gnus.  You'd
have to compose the image yourself, right?  Plus you'd lose the visual
consistency that Silk provides by having individually designed icons.

I have almost convinced myself to make iconset-silk.el an ELPA package
now :) I may also provide a general iconset.el library that would make
it easier to interact with iconset-silk.el symbolically.  Would that be
OK?  Is there already a library to do this?

Ted

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

On Thu, Mar 24 2011, Ted Zlatanov wrote:

> Sorry, I don't know how that would help inside Emacs or Gnus. 

I did not say it would help. :)

> You'd have to compose the image yourself, right?

Yes.

> Plus you'd lose the visual
> consistency that Silk provides by having individually designed icons.

I don't see why since all the icons come from a same set.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> There's two issues.  One, Gnome themes are meant for system
> appearance, NOT for applications...  Two, the standard Gnome icons are
> pretty comprehensive... but they require Gnome.  I think we can do
> better when Gnome is not installed or available.

We may have a slight difference of objectives here.

In the past, we added icons to etc/images as and when various parts of
Emacs require them.  These icons were taken, partly for convenience,
from Gnome.  Later, Jan added support for redirecting to the
system-installed Gnome theme icons, so that Emacs will look nicer on
systems where Gnome is present.

So, the images that we distribute with Emacs are "the images that Emacs
needs".  If Gnus or any other package in Emacs needs extra *specific*
icons, by the way, we should not hesitate to add them to etc/images.

If I understand you correctly, you want something different: for Emacs
to provide a complete set of images that arbitrary Emacs applications
might need.  While I agree that Emacs programmers might be happy with
the easy availability of such icons, adding hundreds of files to the
Emacs tarfile, not directly used by Emacs, strikes me as wasteful.

People make jokes about the Emacs operating system, but in truth we've
placed a lot of emphasis on using existing operating system resources.
Icon sets are an operating system resource.  That's why I was talking
about extending x-gtk-stock-map to other platforms---the idea is to
provide a cross-platform solution for Emacs applications to access the
operating system's icons.

Although adding Silk as an ELPA package is tempting, but I'm not
certain.  Suppose a package wants one single icon from Silk.  If it
depends on the Silk package, installing it means also downloading and
installing the hundreds of Silk icons, which is, again, wasteful.  Or is
the idea to make Silk an optional dependency, so that the package will
display icons only if Silk is installed?

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Ted Zlatanov]

On Thu, 24 Mar 2011 15:06:47 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> So, the images that we distribute with Emacs are "the images that Emacs
CY> needs".  If Gnus or any other package in Emacs needs extra *specific*
CY> icons, by the way, we should not hesitate to add them to etc/images.

OK.

CY> If I understand you correctly, you want something different: for Emacs
CY> to provide a complete set of images that arbitrary Emacs applications
CY> might need.  While I agree that Emacs programmers might be happy with
CY> the easy availability of such icons, adding hundreds of files to the
CY> Emacs tarfile, not directly used by Emacs, strikes me as wasteful.

As I said, it can be a single image or in some other compact format
(e.g. http://www.famfamfam.com/lab/icons/silk/famfamfam_silk_icons_v013.zip
could be used directly).  So I don't think it's wasteful--if anything,
it saves a lot of work maintaining individual images.

CY> People make jokes about the Emacs operating system,

I think even more people use and rely on Emacs every day, and that's
more important :) My proposal aims to improve the Emacs platform so
applications running on it can provide a better user experience.

CY> but in truth we've placed a lot of emphasis on using existing
CY> operating system resources.  Icon sets are an operating system
CY> resource.

I disagree.  Some are provided by the platform but not in a reliable
cross-platform way, and certainly not as conveniently named as Silk's
icons.

CY> That's why I was talking about extending x-gtk-stock-map to other
CY> platforms---the idea is to provide a cross-platform solution for
CY> Emacs applications to access the operating system's icons.

I think that's useful but insufficient.  So I propose iconset.el to
manage the general "give me an icon from iconset X or from a Gnome theme
or from the OS" task.  Then iconset-silk.el for the specific Silk icons;
iconset-gnome.el to manage the Gnome themes and icons, and
iconset-gtk.el to access x-gtk-stock-map.  At the top level the API user
should be able to specify either a semantic meaning ("the best available
icon for the text/plain MIME type") or a specific icon ("the Silk
css_valid icon"), together with a priority list to specify "best."

CY> Although adding Silk as an ELPA package is tempting, but I'm not
CY> certain.  Suppose a package wants one single icon from Silk.  If it
CY> depends on the Silk package, installing it means also downloading and
CY> installing the hundreds of Silk icons, which is, again, wasteful.  Or is
CY> the idea to make Silk an optional dependency, so that the package will
CY> display icons only if Silk is installed?

Yes, I think it will be optional through iconset.el.  When the user
installs iconset-silk.el, iconset.el will automatically provide it.  So
I propose iconset.el (plus the Gnome theme/GTK glue) goes into the Emacs
core, while iconset-silk.el lives in the GNU ELPA.

Ted

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I think that's useful but insufficient.  So I propose iconset.el to
> manage the general "give me an icon from iconset X or from a Gnome theme
> or from the OS" task.  Then iconset-silk.el for the specific Silk icons;
> iconset-gnome.el to manage the Gnome themes and icons, and
> iconset-gtk.el to access x-gtk-stock-map.  At the top level the API user
> should be able to specify either a semantic meaning ("the best available
> icon for the text/plain MIME type") or a specific icon ("the Silk
> css_valid icon"), together with a priority list to specify "best."

Sounds like a good idea.

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Christoph Conrad]

Hi Chong,

* Chong Yidong <cyd@stupidchicken.com> schrieb:

> While I agree that Emacs programmers might be happy with the easy
> availability of such icons, adding hundreds of files to the Emacs
> tarfile, not directly used by Emacs, strikes me as wasteful.

Programmers are able to customize emacs to their needs by adding any
external icon set they need. The everyday user (yes, they exist) is not.

> Or is the idea to make Silk an optional dependency, so that the
> package will display icons only if Silk is installed?

That would be a good opportunity.

Regards,
Christoph

Re: Silk icon set for Gnus and synchronizing it into Emacs

[chad]

On Mar 24, 2011, at 11:17 PM, Christoph Conrad wrote:

>> While I agree that Emacs programmers might be happy with the easy
>> availability of such icons, adding hundreds of files to the Emacs
>> tarfile, not directly used by Emacs, strikes me as wasteful.
> 
> Programmers are able to customize emacs to their needs by adding any
> external icon set they need. The everyday user (yes, they exist) is not.

In what situation does the everyday user want to add an icon to emacs? Programmers adding functionality might easily want new icons for that functionality, but I'm not easily imagining a situation where an `everyday user' would want to add a new icon to emacs without crossing (pretty far, imho) the line into what you seem to be calling a programmer.

Perhaps a user might want to switch all their icons to 'silk versions', something that might reasonably be done in a package.  If that package contained all of the silk icons suggested, hundreds of them would still be wasted space.

What am I missing?
*Chad

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Christoph Conrad]

Hi Chad,

> What am I missing? *Chad

Nothing. I did not think hard enough about that issue.

Regards,
Christoph

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Ted Zlatanov]

On Fri, 25 Mar 2011 09:00:31 -0700 chad <chadpbrown@gmail.com> wrote: 

c> Perhaps a user might want to switch all their icons to 'silk
c> versions', something that might reasonably be done in a package.

Yes, I'll work on iconset*.el to provide this.

c> If that package contained all of the silk icons suggested, hundreds
c> of them would still be wasted space.

Silk is 4 MB unpacked.  I don't think that's wasteful considering the
benefits of a consistent, well-designed, comprehensive set of 700 icons.

As an ELPA package, it will be easy for users to install
iconset-silk.el, but it won't be installed by default.

Ted

Re: Silk icon set for Gnus and synchronizing it into Emacs

[chad]

On Mar 25, 2011, at 9:47 AM, Ted Zlatanov wrote:
> 
> c> If that package contained all of the silk icons suggested, hundreds
> c> of them would still be wasted space.
> 
> Silk is 4 MB unpacked.  I don't think that's wasteful considering the
> benefits of a consistent, well-designed, comprehensive set of 700 icons.

I understand that space is cheap, but under what circumstances will, (at a generous guess), 600 of those 700 icons *ever* be used? All the circumstances I see include a step like ``...and a developer writes some code that adds a button, using a currently-unused icon from the silk set...'' - at which point the developer will 99% of the time pick the icon and include it in the library/package anyway.

What am I missing?
*Chad

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Ted Zlatanov]

On Mon, 28 Mar 2011 11:09:53 -0700 chad <chadpbrown@gmail.com> wrote: 

c> On Mar 25, 2011, at 9:47 AM, Ted Zlatanov wrote:
>> 
c> If that package contained all of the silk icons suggested, hundreds
c> of them would still be wasted space.
>> 
>> Silk is 4 MB unpacked.  I don't think that's wasteful considering the
>> benefits of a consistent, well-designed, comprehensive set of 700 icons.

c> I understand that space is cheap, but under what circumstances will,
c> (at a generous guess), 600 of those 700 icons *ever* be used?

I can go through Emacs and point out uses for all of those icons.  The
question is really "will they get used?" and I believe so, partly
because I'll try to convince developers to use them by making iconset.el
really convenient compared to:

c> All the circumstances I see include a step like ``...and a developer
c> writes some code that adds a button, using a currently-unused icon
c> from the silk set...'' - at which point the developer will 99% of the
c> time pick the icon and include it in the library/package anyway.

So, the idea is to provide iconset.el+iconset-silk.el so developers
don't have to do this elementary, repetitive, wasteful work, and so they
don't end up with the Gnus situation where a collection of icons is
thrown into a directory and... that's it.

Ted

Re: Silk icon set for Gnus and synchronizing it into Emacs

[chad]

On Mar 28, 2011, at 11:27 AM, Ted Zlatanov wrote:
> So, the idea is to provide iconset.el+iconset-silk.el so developers
> don't have to do this elementary, repetitive, wasteful work,

Ah, I didn't understand that the package would somehow provide code support for making it easier for developers to add icons to things; I read your description as a package for users, not for developers.  That's what I was missing.  Thanks.

I had vaguely in mind asking if anyone was interested in adding icon selection to the upcoming themes support, but decided it was too much like asking someone else to implement my idea. Since you're already on the trail, I wonder if you've given this any thought? 

*Chad

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Ted Zlatanov]

On Mon, 28 Mar 2011 13:03:32 -0700 chad <chadpbrown@gmail.com> wrote: 

c> I had vaguely in mind asking if anyone was interested in adding icon
c> selection to the upcoming themes support, but decided it was too much
c> like asking someone else to implement my idea. Since you're already on
c> the trail, I wonder if you've given this any thought?

No, I haven't.  I don't know much about this upcoming support, do you
mean cus-theme.el?

Ted

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Jan Djärv]

Ted Zlatanov skrev 2011-03-28 20.27:
> On Mon, 28 Mar 2011 11:09:53 -0700 chad<chadpbrown@gmail.com>  wrote:
>
> c>  On Mar 25, 2011, at 9:47 AM, Ted Zlatanov wrote:
>>>
> c>  If that package contained all of the silk icons suggested, hundreds
> c>  of them would still be wasted space.
>>>
>>> Silk is 4 MB unpacked.  I don't think that's wasteful considering the
>>> benefits of a consistent, well-designed, comprehensive set of 700 icons.
>
> c>  I understand that space is cheap, but under what circumstances will,
> c>  (at a generous guess), 600 of those 700 icons *ever* be used?
>
> I can go through Emacs and point out uses for all of those icons.

Really?  Where does database* go?  And building* ? world*? camera*?
Maybe there are elisp packages that can use them, but core Emacs?

	Jan D.

Re: Silk icon set for Gnus and synchronizing it into Emacs

[Ted Zlatanov]

On Mon, 28 Mar 2011 22:35:24 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote: 

JD> Ted Zlatanov skrev 2011-03-28 20.27:

>> I can go through Emacs and point out uses for all of those icons.

JD> Really?  Where does database* go?  And building* ? world*? camera*?
JD> Maybe there are elisp packages that can use them, but core Emacs?

(for the impatient: you can see all the icons at
http://www.famfamfam.com/lab/icons/silk/previews/index_abc.png)

First of all, the intent is to provide a core facility to ELisp
packages, not just the Emacs core.  So we can use them in the core but
the iconset-silk package will not be in the core but in the GNU ELPA
(see earlier discussion).  I was sort of thinking of the extended Emacs
ecosphere, including the ELPAs and so on.  So here are some guesses for
the core:

The database* icons could be used for the sql.el library.

building* I don't know.  That one is kind of weird.  Maybe for the
compilation error log, but that's a stretch.

world* could be used for internationalization or web-related icons.

camera* can be used for image management, together with image*, say when
an image has the camera's manufacturer model embedded.

Ted