emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ted Zlatanov
Subject: Re: Silk icon set for Gnus and synchronizing it into Emacs
Date: Thu, 24 Mar 2011 15:27:26 -0500
User-agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)

On Thu, 24 Mar 2011 15:06:47 -0400 Chong Yidong <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]