Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <address@hidden> wrote:

> On Sun, Oct 16 2005, Bill Wohler wrote:
> 
> > Also, the images can be shared by other applications (I hope that
> > this will be the case with Gnus soon) so this naming would avoid
> > having multiple copies of the same image.
> 
> What do you think about my suggestions on using GNOME stock icons?
> IMHO those look much nicer than the current Gnus icons and fit much
> better into the rest of the Emacs icons.
> 
> See <URL:http://thread.gmane.org/v94q87ogsp.fsf%40marauder.physik.uni-ulm.de>
> and <URL:http://theotp1.physik.uni-ulm.de/~ste/comp/emacs/gnus/tool-bar/>.

Reiner,

Many of the Emacs icons came from Gnome back in 2000; I recently added a
refresh icon from Gnome 2.10. It would be good to update them all.
Perhaps someone more legally minded can speak to the license or
copyright issues.

Anyway, thanks for bringing this up. I had planned to send a note to the
Gnus folks soon regarding the icons, but I may as well make it now.

I am following the good example set by the Gnus folks and will soon
(this afternoon?) check in a change into GNU Emacs that moves *all* of
the images from lisp/toolbar to etc/images.

In addition, Stallman wanted me to replace the underscore (_) in
filenames with dashes (-) while I was at it so the names conform with
Emacs policy. I also placed mail_compose and mail_send into mail/compose
and mail/send. I updated gnus/message.el as a result of the former
change.

It would great if Gnus and MH-E could share images where it makes sense
to do so. For example, would the Gnus folks mind using mail/reply
instead of gnus/reply? The Debian (and other distributions) MH-E and
Gnus maintainers might discuss creating a shared image package and
having the MH-E and Gnus packages depend on that or Emacs 22.

Another new policy is that images must be fully qualified relative to
the etc/images directory. Instead of reply, mail/reply must be used.
This removes the chance of name collisions. That means
nnheader-find-etc-directory must not add gnus to the path element.

A new feature of Emacs 22 is an image-load-path variable used by
find-image. The image-load-path variable contains the symbol load-path
for backwards compatibility.

I wrote mh-image-load-path based upon your nnheader-find-etc-directory
and another one I can't remember now to update image-load-path or
load-path based upon the MH-E library. It would be good to generalize it
so that we can share it. What do you think about my renaming it to
something like generate-image-load-path, adding a PACKAGE argument, and
adding it to image.el? Then we can define it with (if (not (fboundp
'generate-image-load-path ...))) in our code to work with Emacs 20 and
21.

(defun mh-image-load-path ()
  "Ensure that the MH-E images are accessible by `find-image'.
Images for MH-E are found in ../../etc/images relative to the files in
`lisp/mh-e'. If `image-load-path' exists (since Emacs 22), then the images
directory is added to it if isn't already there. Otherwise, the images
directory is added to the `load-path' if it isn't already there."
  (unless mh-image-load-path-called-flag
    (let (mh-library-name mh-image-load-path)
      ;; First, find mh-e in the load-path.
      (setq mh-library-name (locate-library "mh-e"))
      (if (not mh-library-name)
        (error "Can not find MH-E in load-path"))
      (setq mh-image-load-path
            (expand-file-name (concat (file-name-directory mh-library-name)
                                      "../../etc/images")))
      (if (not (file-exists-p mh-image-load-path))
          (error "Can not find image directory %s" mh-image-load-path))
      (if (boundp 'image-load-path)
          (add-to-list 'image-load-path mh-image-load-path)
        (add-to-list 'load-path mh-image-load-path)))
    (setq mh-image-load-path-called-flag t)))


-- 
Bill Wohler <address@hidden>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.