Sharing mail icons between MH-E and Gnus (was: debian changelog,1.39,1.40 control,1.29,1.30 dirs,1.2,1.3 emacsen-install,1.5,1.6 emacsen-startup,1.12,1.13 rules,1.12,1.13)

Sharing mail icons between MH-E and Gnus (was: debian changelog,1.39,1.40 control,1.29,1.30 dirs,1.2,1.3 emacsen-install,1.5,1.6 emacsen-startup,1.12,1.13 rules,1.12,1.13)

[Reiner Steib]

[ The following message is a courtesy copy of an article that has
  been posted to news:gmane.mail.mh-e.devel as well. ]

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/>.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> 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 <wohler@newt.com>  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.

Re: Sharing mail icons between MH-E and Gnus

[Reiner Steib]

On Mon, Oct 17 2005, Bill Wohler wrote:

[ Sorry for the late reply, Bill. ]

> Reiner Steib <reinersteib+gmane@imap.cc> 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.

If I understand Richard's response correctly we can use the Gnome
icons.  (See <http://article.gmane.org/gmane.emacs.devel/43394> and
etc/images/README in Emacs CVS.)

As moving/renaming files around in CVS is not supported, I'd like to
hear comments from Gnus and MH-E developers on the filenames and
directories.  If the MH-E developers consider to also use some of the
suggested Gnome icons (now or in the future) I will probably use
etc/images/mail/*.xpm and etc/images/*.xpm (where appropriate) instead
of etc/images/gnus/*.xpm in Gnus' repository (we don't have
etc/images/mail yet).

(I don't plan to put the new icons into Gnus' stable branch (v5-10)
which is synced with Emacs 22.)

Below is an assignment list from Gnome stock icon names and the names
I intend to use in Gnus.  I didn't address the directory prefix issue
("gnus/" or "mail/", see below) yet.  

--8<---------------cut here---------------start------------->8---
# Location of the Gnome icons (converted to xpm from png) on my system:
g=/usr/local/share/icons/gnome
# Name in Gnus CVS repository:
ei=etc/images

# [ candidates for "etc/images/mail/"? ]

  $g/stock_mail-compose.xpm            $ei/gnus/compose.xpm
  $g/stock_mail-flag-for-followup.xpm  $ei/gnus/flag-followup.xpm
  $g/stock_mail-forward.xpm            $ei/gnus/forward.xpm
  $g/stock_mail-handling.xpm           $ei/gnus/save-draft.xpm
  $g/stock_mail-reply.xpm              $ei/gnus/reply-author.xpm
  $g/stock_mail-reply-to-all.xpm       $ei/gnus/reply-all.xpm
  $g/stock_mail-send.xpm               $ei/gnus/send.xpm
  $g/stock_attach.xpm                  $ei/gnus/attach.xpm
  # We should have a mail-preview icon with an envelope as in
  # stock_mail-reply.  The name preview.xpm was also used by
  # preview-latex.  There might be a print-preview in the future.  So
  # let's be more specific (maybe not necessary if we have "gnus/" or
  # "mail/" prefix).
  $ei/gnus/preview.xpm                 $ei/gnus/mail-preview.xpm

# [ candidates for "etc/images/"? ]

  $g/stock_connect.xpm                 $ei/gnus/connect.xpm
  $g/stock_delete.xpm                  $ei/gnus/delete.xpm
  $g/stock_dialog-info.xpm             $ei/gnus/describe.xpm
  $g/stock_disconnect.xpm              $ei/gnus/disconnect.xpm
  $g/stock_exit.xpm                    $ei/gnus/exit-mode.xpm
  $g/stock_lock.xpm                    $ei/gnus/lock.xpm
  $g/stock_refresh.xpm                 $ei/gnus/refresh.xpm
  $g/stock_sort-ascending.xpm          $ei/gnus/sort-a-z.xpm
  $g/stock_sort-column-ascending.xpm   $ei/gnus/sort-1-9.xpm
  $g/stock_spam.xpm                    $ei/gnus/spam.xpm
  $g/stock_not-spam.xpm                $ei/gnus/not-spam.xpm
  # sep.xpm is from AUCTeX:
  $g/sep.xpm                           $ei/gnus/separator.xpm
--8<---------------cut here---------------end--------------->8---

<http://theotp1.physik.uni-ulm.de/~ste/comp/emacs/gnus/tool-bar/Gnome-to-Gnus.png>
contains an overview of all icons I intend to import to Gnus and their
proposed filename in Gnus.

> 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?

I don't like mail/reply-{all,from,to}.xpm.  If adding text inside the
icon is necessary to make clear which action is performed, the graphic
should be improved.  See the updated page
<http://theotp1.physik.uni-ulm.de/~ste/comp/emacs/gnus/tool-bar/#gnome>
for my suggestion using Gnome icons for Gnus.  MH-E's mail/compose.xpm
and mail/send.xpm icons would be okay, but I'd prefer to use the Gnome
icons if suitable icons are available in Gnome.

As you can see from the above web page and the list above, we'd have
name collisions for reply-all.xpm (if we use mail/reply-all instead of
gnus/reply-all).

> 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.

I will have to look into this.

> 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.

A good idea, IMHO.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Mon, Oct 17 2005, Bill Wohler wrote:
> 
> [ Sorry for the late reply, Bill. ]

Me too ;-). I just wanted to let you know I'll address your email when I
have a bit more time. Soon, as it would be nice to get these details
worked out before the Emacs 22 release.

-- 
Bill Wohler <wohler@newt.com>  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.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Mon, Oct 17 2005, Bill Wohler wrote:
> 
> If I understand Richard's response correctly we can use the Gnome
> icons.  (See <http://article.gmane.org/gmane.emacs.devel/43394> and
> etc/images/README in Emacs CVS.)

Excellent.

>               If the MH-E developers consider to also use some of the
> suggested Gnome icons (now or in the future) I will probably use
> etc/images/mail/*.xpm and etc/images/*.xpm (where appropriate) instead
> of etc/images/gnus/*.xpm in Gnus' repository (we don't have
> etc/images/mail yet).

Good. That's what I was hoping.

> (I don't plan to put the new icons into Gnus' stable branch (v5-10)
> which is synced with Emacs 22.)

Why not? I was hoping this would be done for Emacs 22.

> Below is an assignment list from Gnome stock icon names and the names
> I intend to use in Gnus.  I didn't address the directory prefix issue
> ("gnus/" or "mail/", see below) yet.  

Thanks very much for doing this. I've added the existing non-gnus names
that MH-E/Emacs would like to use as well. (I dropped the suffixes so
the table would fit.) Proposed names where icons don't yet exist are in
square brackets ([]). I've indicated icons used by Gnus but not by MH-E
or the rest of Emacs with a dash; this means we do not necessarily have
to move them out of the gnus directory at this time. I agree with your
observation about mail-preview.xpm (that we should have a specific one.

  g=/usr/local/share/icons/gnome or /usr/share/icons/hicolor/24x24/stock
  ei=$EMACS/etc/images

  $g/stock_mail-compose            $ei/gnus/compose        $ei/mail/compose
  $g/stock_mail-flag-for-followup  $ei/gnus/flag-followup  $ei/highlight ?
  $g/stock_mail-forward            $ei/gnus/forward        [$ei/mail/forward]
  $g/stock_mail-handling           $ei/gnus/save-draft     -
  $g/stock_mail-reply              $ei/gnus/reply-author   $ei/mail/reply
  $g/stock_mail-reply-to-all       $ei/gnus/reply-all      $ei/mail/reply-all
  $g/stock_mail-send               $ei/gnus/send           $ei/mail/send
  $g/stock_attach                  $ei/gnus/attach         $ei/mail/attach
  $ei/gnus/preview                 $ei/gnus/mail-preview   [$ei/mail/preview]

  $g/stock_connect                 $ei/gnus/connect        -
  $g/stock_delete                  $ei/gnus/delete         [$ei/delete]
  $g/stock_dialog-info             $ei/gnus/describe       -
  $g/stock_disconnect              $ei/gnus/disconnect     -
  $g/stock_exit                    $ei/gnus/exit-mode      $ei/exit
  $g/stock_lock                    $ei/gnus/lock           -
  $g/stock_refresh                 $ei/gnus/refresh        $ei/refresh
  $g/stock_sort-ascending          $ei/gnus/sort-a-z       [$ei/sort-ascending]
  $g/stock_sort-column-ascending   $ei/gnus/sort-1-9       [$ei/sort-column-ascending]
  $g/stock_spam                    $ei/gnus/spam           [$ei/mail/spam]
  $g/stock_not-spam                $ei/gnus/not-spam       [$ei/mail/not-spam]
  $g/sep                           $ei/gnus/separator      -

I've added a few more icons to grab from GNOME:

  $g/stock_contact                 -                       $ei/mail/alias -> $ei/contact?
  $g/stock_mail-copy               -                       [$ei/mail/copy]
  $g/stock_mail-move               -                       $ei/mail/refile -> $ei/mail/move?
  $g/stock_inbox                   -                       $ei/mail -> $ei/inbox ?
  $g/stock_compile                 -		           $ei/mail/repack?
  $g/stock_zoom-out                -                       $ei/mail/widen

If you're going to move the sort icons, you might as well take this
opportunity to use the GNOME names to make it easier to see from whence
they came. I also proposed a couple of renames for MH-E icons too.

I'd like to update $ei/show, but there doesn't seem to be an equivalent
GNOME icon for this. I could take stock_new and add a bit of "text" to
it. Another idea that occurred to me was using stock_mail-open, but then
we'd have to move it to $ei/mail/open (and could probably delete
$ei/show). Peter?

Fortunately, it looks like most of the other Emacs icons have already
been updated.

> > 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?
> 
> I don't like mail/reply-{all,from,to}.xpm.  If adding text inside the
> icon is necessary to make clear which action is performed, the graphic
> should be improved.

For consistency, I'm happy to use reply.xpm instead of reply-from.xpm
and use the GNOME reply-all.xpm icon instead of ours. We could also
potentially drop the reply-to.xpm icon. Do any MH-E users use it?

>                                        but I'd prefer to use the Gnome
> icons if suitable icons are available in Gnome.

Me too.

> As you can see from the above web page and the list above, we'd have
> name collisions for reply-all.xpm (if we use mail/reply-all instead of
> gnus/reply-all).

Not if we go with the GNOME icons.

I hope you have time to make these updates. I'm going to be hard-pressed
to get the MH-E manual done in time as it is.

In case you find it useful, I got the following tip for creating
Emacs-compatible .pbm images from jan.h.d@swipnet.se.

  1. Edit .xpm image in GIMP.
  2. Image > Mode > Indexed. Check Use Black/White Palette and No
     Color Dithering.
  3. File > Save As file.xbm.
  4. Run xbmtopbm < file.xbm > file.pbm.

> > 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.
> 
> A good idea, IMHO.

Thanks. mh-image-load-path has morphed a bit in the past week. I have
yet to give some thought to generalizing it. If I did so, would you have
time to update Gnus to use it?

-- 
Bill Wohler <wohler@newt.com>  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.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Reiner Steib]

On Sun, Feb 19 2006, Bill Wohler wrote:

[ I'll only respond to parts of your mail later in a separate mail. ]

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> Thanks very much for doing this. I've added the existing non-gnus names
> that MH-E/Emacs would like to use as well. (I dropped the suffixes so
> the table would fit.) Proposed names where icons don't yet exist are in
> square brackets ([]). I've indicated icons used by Gnus but not by MH-E
> or the rest of Emacs with a dash; this means we do not necessarily have
> to move them out of the gnus directory at this time. I agree with your
> observation about mail-preview.xpm (that we should have a specific one.
>
>   g=/usr/local/share/icons/gnome or /usr/share/icons/hicolor/24x24/stock
>   ei=$EMACS/etc/images
>
>   $g/stock_mail-compose            $ei/gnus/compose        $ei/mail/compose

OK.

>   $g/stock_mail-flag-for-followup  $ei/gnus/flag-followup  $ei/highlight ?

Maybe a more generic name such as $ei/flag-red?  I'm not sure.

>   $g/stock_mail-forward            $ei/gnus/forward        [$ei/mail/forward]
>   $g/stock_mail-handling           $ei/gnus/save-draft     -

We should use $ei/mail/save-draft, I think.

>   $g/stock_mail-reply              $ei/gnus/reply-author   $ei/mail/reply
>   $g/stock_mail-reply-to-all       $ei/gnus/reply-all      $ei/mail/reply-all
>   $g/stock_mail-send               $ei/gnus/send           $ei/mail/send
>   $g/stock_attach                  $ei/gnus/attach         $ei/mail/attach
>   $ei/gnus/preview                 $ei/gnus/mail-preview   [$ei/mail/preview]
>
>   $g/stock_connect                 $ei/gnus/connect        -
>   $g/stock_delete                  $ei/gnus/delete         [$ei/delete]
>   $g/stock_dialog-info             $ei/gnus/describe       -
>   $g/stock_disconnect              $ei/gnus/disconnect     -
>   $g/stock_exit                    $ei/gnus/exit-mode      $ei/exit

There is already an icon "exit.xpm" in Emacs (with a smaller door and
arrow compared to $g/stock_exit.  Apparently it's unused.  I'd also
vote for replacing it with stock_exit.

>   $g/stock_refresh                 $ei/gnus/refresh        $ei/refresh

See below (stock_inbox).

>   $g/stock_sort-ascending          $ei/gnus/sort-a-z       [$ei/sort-ascending]
>   $g/stock_sort-column-ascending   $ei/gnus/sort-1-9       [$ei/sort-column-ascending]
[ Re-ordered quoting: ]
> If you're going to move the sort icons, you might as well take this
> opportunity to use the GNOME names to make it easier to see from whence
> they came.

I shortened the names to avoid name collisions for 8.3 systems
(e.g. sort-column-ascending vs. sort-column-descending).  Additionally
the names don't reflect the images' content.  Maybe because the Gnome
icons are intended for spread sheets applications where letters
indicate rows and numbers indicate columns.

>   $g/stock_spam                    $ei/gnus/spam           [$ei/mail/spam]
>   $g/stock_not-spam                $ei/gnus/not-spam       [$ei/mail/not-spam]
>   $g/sep                           $ei/gnus/separator      -
>
> I've added a few more icons to grab from GNOME:
>
>   $g/stock_contact                 -                       $ei/mail/alias -> $ei/contact?

$ei/contact seems more suitable.  We don't have a related Gnus command
for this icon, but users might bind it to `bbdb/gnus-show-sender' (or
we could add this tool bar icon by default if `bbdb/gnus-show-sender'
is bound).

>   $g/stock_mail-copy               -                       [$ei/mail/copy]
>   $g/stock_mail-move               -                       $ei/mail/refile -> $ei/mail/move?

I don't know about MH-E, but for Gnus I'd not have these functions on
the tool bar, because the user has to choose the target via the
mini-buffer prompt (keyboard) after a mouse click.  (Not a good UI, I
think.)

>   $g/stock_inbox                   -                       $ei/mail -> $ei/inbox ?

In the meantime, I also use stock_inbox (for
`gnus-summary-insert-new-articles' in the summary and
`gnus-group-get-new-news' in the group buffer) instead of
stock_refresh.

>   $g/stock_compile                 -		           $ei/mail/repack?

[In Gnus, somehow similar commands would be
`gnus-group-expire-all-groups' and `gnus-summary-expire-articles'.]
But the image stock_compile probably is supposed to visualize batch
processing, isn't it?

>   $g/stock_zoom-out                -                       $ei/mail/widen

Maybe we should add stock_zoom{,-in,out,prev,next,shift} as $ei/zoom*?
The zoom images aren't mail-specific.  In Gnus, they could be used for
some of the limiting commands, (info "(gnus)Limiting").

> I'd like to update $ei/show, but there doesn't seem to be an equivalent
> GNOME icon for this. I could take stock_new and add a bit of "text" to
> it. Another idea that occurred to me was using stock_mail-open, but then
> we'd have to move it to $ei/mail/open (and could probably delete
> $ei/show). Peter?
[ A MH-E issue, AFAIU. ]

> Fortunately, it looks like most of the other Emacs icons have already
> been updated.

Yes.

>> As you can see from the above web page and the list above, we'd have
>> name collisions for reply-all.xpm (if we use mail/reply-all instead of
>> gnus/reply-all).
>
> Not if we go with the GNOME icons.

:-)

> In case you find it useful, I got the following tip for creating
> Emacs-compatible .pbm images from jan.h.d@swipnet.se.
>
>   1. Edit .xpm image in GIMP.
>   2. Image > Mode > Indexed. Check Use Black/White Palette and No
>      Color Dithering.
>   3. File > Save As file.xbm.
>   4. Run xbmtopbm < file.xbm > file.pbm.

Should be scriptable.  Below is my first Gimp script.  I used to
convert the Gnome PNG icons to XPM; convert(1) didn't work well for
this.  Any volunteers?

--8<---------------cut here---------------start------------->8---
;; -*- scheme -*-
;; Put this file in ~/.gimp-*/scripts/ (e.g. as rs-convert.scm).

;; gimp -i -b '(rs-save-as-xpm "foo.png" "foo.xpm" 127)'  '(gimp-quit 0)'

;; Maybe someone could add the steps described in
;; http://article.gmane.org/gmane.emacs.devel/35176 here?
;; | Gimp, I don't remember the details, but convert to indexed, and reduce 
;; | colors and choose palette when doing that.  Then save as xpm, setting 
;; | alpha to 255.  I don't think it was any more steps.

(define (rs-save-as-xpm filename filename2 threshold)
  (let* ((image (car (gimp-file-load RUN-NONINTERACTIVE filename filename)))
         (drawable (car (gimp-image-get-active-layer image))))
    ;; (unless threshold (setq threshold 127))
    (file-xpm-save RUN-NONINTERACTIVE image drawable
                   filename2 filename2 threshold)
    (gimp-image-delete image)))
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Sun, Feb 19 2006, Bill Wohler wrote:
> 
> > Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> 
> >   $g/stock_mail-handling           $ei/gnus/save-draft     -
> 
> We should use $ei/mail/save-draft, I think.

OK.

> >   $g/stock_sort-ascending          $ei/gnus/sort-a-z       [$ei/sort-ascending]
> >   $g/stock_sort-column-ascending   $ei/gnus/sort-1-9       [$ei/sort-column-ascending]
> [ Re-ordered quoting: ]
> > If you're going to move the sort icons, you might as well take this
> > opportunity to use the GNOME names to make it easier to see from whence
> > they came.
> 
> I shortened the names to avoid name collisions for 8.3 systems
> (e.g. sort-column-ascending vs. sort-column-descending).

Good point.

>                                                           Additionally
> the names don't reflect the images' content.

They aren't supposed to since the images' content can change depending
on locale (or skill of artist). Names reflect the images' action. For
example, you use "stop", not "red-hexagon", since in some locales stop
is an entirely different image.

> >   $g/stock_contact                 -                       $ei/mail/alias -> $ei/contact?
> 
> $ei/contact seems more suitable.  We don't have a related Gnus command
> for this icon, but users might bind it to `bbdb/gnus-show-sender' (or
> we could add this tool bar icon by default if `bbdb/gnus-show-sender'
> is bound).

Oops, this shows how important good names are. You interpreted this as
"Show Contact", but that's not what MH-E does with it. The MH-E action
for this image is to add the sender of the current message to
~/Mail/aliases. I suppose $ie/add-contact would be a better name, since
it is general and could be used both by MH-E and BBDB. Would something
like "$ie/show-contact" work instead of bbdb/gnus-show-sender? For
completeness, "$ie/list-contacts" would also be useful as well. Which
GNOME images would you use to indicate these actions?

> >   $g/stock_mail-copy               -                       [$ei/mail/copy]
> >   $g/stock_mail-move               -                       $ei/mail/refile -> $ei/mail/move?
> 
> I don't know about MH-E, but for Gnus I'd not have these functions on
> the tool bar, because the user has to choose the target via the
> mini-buffer prompt (keyboard) after a mouse click.  (Not a good UI, I
> think.)

Are you saying then that only keyboard commands can be used for commands
that have minibuffer input? I think I disagree. The tool bar and menu
helps the user discover functionality. Many commands, such as Save As,
require minibuffer input and are common in menus and tool bars. Commands
that require further input are indicated in menus with ellipsis ("...").

> 
> >   $g/stock_inbox                   -                       $ei/mail -> $ei/inbox ?
> 
> In the meantime, I also use stock_inbox (for
> `gnus-summary-insert-new-articles' in the summary and
> `gnus-group-get-new-news' in the group buffer) instead of
> stock_refresh.

In MH (and MH-E), inc and scan are two separate commands and therefore
(can) have two separate icons (inbox and refresh respectively).

> >   $g/stock_compile                 -		           $ei/mail/repack?
> 
> [In Gnus, somehow similar commands would be
> `gnus-group-expire-all-groups' and `gnus-summary-expire-articles'.]
> But the image stock_compile probably is supposed to visualize batch
> processing, isn't it?

Yes. I wasn't trying to say that "repack" was like "compile", but rather
that the current GNOME icon for "compile" seemed to be a better image
than what we currently have. The question mark above indicates that I
was fishing for other opinions since I wasn't 100% positive.

> >   $g/stock_zoom-out                -                       $ei/mail/widen
> 
> Maybe we should add stock_zoom{,-in,out,prev,next,shift} as $ei/zoom*?
> The zoom images aren't mail-specific.  In Gnus, they could be used for
> some of the limiting commands, (info "(gnus)Limiting").

Agreed.

-- 
Bill Wohler <wohler@newt.com>  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.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Reiner Steib]

On Mon, Feb 20 2006, Bill Wohler wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
>> On Sun, Feb 19 2006, Bill Wohler wrote:
>> > If you're going to move the sort icons, you might as well take this
>> > opportunity to use the GNOME names to make it easier to see from whence
>> > they came.

I forgot to mention that I intend to document where the icons come
from like it was done in emacs/etc/image/README (probably adding the
stock_... names).
 
> They aren't supposed to since the images' content can change depending
> on locale (or skill of artist). Names reflect the images' action. For
> example, you use "stop", not "red-hexagon", since in some locales stop
> is an entirely different image.

OK.  But do you agree to $ei/sort-1-9 and $ei/sort-a-z given the 8.3
problem?

>> >   $g/stock_contact                 -                       $ei/mail/alias -> $ei/contact?
>> 
>> $ei/contact seems more suitable.  We don't have a related Gnus command
>> for this icon, but users might bind it to `bbdb/gnus-show-sender' (or
>> we could add this tool bar icon by default if `bbdb/gnus-show-sender'
>> is bound).
>
> Oops, this shows how important good names are. You interpreted this as
> "Show Contact", but that's not what MH-E does with it. The MH-E action
> for this image is to add the sender of the current message to
> ~/Mail/aliases. I suppose $ie/add-contact would be a better name, since
> it is general and could be used both by MH-E and BBDB. Would something
> like "$ie/show-contact" work instead of bbdb/gnus-show-sender? For
> completeness, "$ie/list-contacts" would also be useful as well. Which
> GNOME images would you use to indicate these actions?

Since Gnus doesn't provide contact/alias management (beside interfaces
to BBDB, ~/.mailrc, ...) it's not very important for us.  Let's add
what you think is useful for MH-E.

[ mail/copy, mail/move ]
>> I don't know about MH-E, but for Gnus I'd not have these functions on
>> the tool bar, because the user has to choose the target via the
>> mini-buffer prompt (keyboard) after a mouse click.  (Not a good UI, I
>> think.)
>
> Are you saying then that only keyboard commands can be used for commands
> that have minibuffer input? I think I disagree. 

I only talked about tool bars (and the mouse-1 action).

> The tool bar and menu helps the user discover functionality. Many
> commands, such as Save As, 

"Save As", "Open File", ... in a GTK build of Emacs 22 pop up the
graphical file selector (by default, see `use-file-dialog').

> require minibuffer input and are common in menus and tool bars.

That fact that it is common in Emacs doesn't make it good. :-)
See this related thread on emacs-devel:
http://article.gmane.org/gmane.emacs.devel/50205
http://thread.gmane.org/gmane.emacs.devel/50205

I often saw my colleagues starring at the screen not realizing that
they need to use the minibuffer after pressing the "Open File" or "New
File" buttons in Emacs 21.

Nevertheless I think adding mail/copy and mail/move is fine.  Which
icons you add by default in MH-E of course is up to you.

>> >   $g/stock_inbox                   -                       $ei/mail -> $ei/inbox ?
>> 
>> In the meantime, I also use stock_inbox (for
>> `gnus-summary-insert-new-articles' in the summary and
>> `gnus-group-get-new-news' in the group buffer) instead of
>> stock_refresh.
>
> In MH (and MH-E), inc and scan are two separate commands and therefore
> (can) have two separate icons (inbox and refresh respectively).

Okay, we can add both.  There's already refresh.xpm (from Gnome) in
Emacs.

>> >   $g/stock_compile                 -		           $ei/mail/repack?
>> 
>> [In Gnus, somehow similar commands would be
>> `gnus-group-expire-all-groups' and `gnus-summary-expire-articles'.]
>> But the image stock_compile probably is supposed to visualize batch
>> processing, isn't it?
>
> Yes. I wasn't trying to say that "repack" was like "compile", but rather
> that the current GNOME icon for "compile" seemed to be a better image
> than what we currently have. The question mark above indicates that I
> was fishing for other opinions since I wasn't 100% positive.

Okay, so this is still open.

>> >   $g/stock_zoom-out                -                       $ei/mail/widen
>> 
>> Maybe we should add stock_zoom{,-in,out,prev,next,shift} as $ei/zoom*?
>> The zoom images aren't mail-specific.  [...]
>
> Agreed.

I'll add them to my list.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Mon, Feb 20 2006, Bill Wohler wrote:
> 
> > Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> >> On Sun, Feb 19 2006, Bill Wohler wrote:
> >> > If you're going to move the sort icons, you might as well take this
> >> > opportunity to use the GNOME names to make it easier to see from whence
> >> > they came.
> 
> I forgot to mention that I intend to document where the icons come
> from like it was done in emacs/etc/image/README (probably adding the
> stock_... names).

I think you mentioned that. We'd definitely do that in any case, but we
should be consistent when we can so that one doesn't necessarily need
the README.

> > They aren't supposed to since the images' content can change depending
> > on locale (or skill of artist). Names reflect the images' action. For
> > example, you use "stop", not "red-hexagon", since in some locales stop
> > is an entirely different image.
> 
> OK.  But do you agree to $ei/sort-1-9 and $ei/sort-a-z given the 8.3
> problem?

Note that the existing GNOME names are (dropping $g/stock_):

  sort-ascending.png
  sort-column-ascending.png
  sort-criteria.png
  sort-descending.png
  sort-row-ascending.png

All of these names are unique in the first eight characters so my
inclination is to go with them. sort-a-z is bad since it implies letters
whereas sort-ascending can apply to anything that can be sorted (such as
animals, or beans). sort-1-9 is bad for the same reason, plus it doesn't
discern between rows or columns. We're in a bit of a pickle, however, if
someday sort-column-descending or sort-row-descending were added. On the
other hand, if these aren't already in GNOME, perhaps we don't have to
worry about it.

> I often saw my colleagues starring at the screen not realizing that
> they need to use the minibuffer after pressing the "Open File" or "New
> File" buttons in Emacs 21.

Yeah, you're right. Using the minibuffer when using GUI items (tool bars
and menus) is a bad idea.

> > The tool bar and menu helps the user discover functionality. Many
> > commands, such as Save As, 
> 
> "Save As", "Open File", ... in a GTK build of Emacs 22 pop up the
> graphical file selector (by default, see `use-file-dialog').

Then we should too. I've added a bug report at SourceForge for this.

-- 
Bill Wohler <wohler@newt.com>  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.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Icons for frequently used sort commands (was: Sharing mail icons between MH-E and Gnus)

[Reiner Steib]

On Tue, Feb 21 2006, Bill Wohler wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
>> On Mon, Feb 20 2006, Bill Wohler wrote:
[...]
> I think you mentioned that. We'd definitely do that in any case, but we
> should be consistent when we can so that one doesn't necessarily need
> the README.

ACK.

> Note that the existing GNOME names are (dropping $g/stock_):
>
>   sort-ascending.png
>   sort-column-ascending.png
>   sort-criteria.png
>   sort-descending.png
>   sort-row-ascending.png
>
> All of these names are unique in the first eight characters so my
> inclination is to go with them. sort-a-z is bad since it implies letters
> whereas sort-ascending can apply to anything that can be sorted (such as
> animals, or beans). sort-1-9 is bad for the same reason, plus it doesn't
> discern between rows or columns. We're in a bit of a pickle, however, if
> someday sort-column-descending or sort-row-descending were added. On the
> other hand, if these aren't already in GNOME, perhaps we don't have to
> worry about it.

Those names make sense for Gnome, but not necessarily for Gnus.  Let
me explain why I suggested those names.  In Gnus we have don't have
any row-sorting commands.  What I had in mind for Gnus (but not in the
default tool bar anyhow, because most user probably have configured a
favorite permanent sorting depending on the group) were
`gnus-summary-sort-by-author' where sort-ascending fits because of the
"A-Z" and `gnus-summary-sort-by-date' where sort-column-ascending fits
because of the "1-9" in the icons.  It's hard to guess what sort
commands are frequently used by users as we have dozens of them, see
(info "(gnus)Summary Sorting") and (info "(gnus)Sorting Groups").

Maybe it's best to go with the Gnome names as you suggest resolving
the 8.3 problem in some way.  As mentioned above, icons for sorting
don't have the highest priority in Gnus.

It would be good to have feedback which kind of sort command are
frequently used.  Maybe Adam Sjøgren (or other people) could make
suitable icons for the most common (Gnus) sort commands.
Which sort command do you use frequently?  It doesn't matter whether
you use the menu or a key binding.  Please give us some feedback!

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642

Re: Icons for frequently used sort commands (was: Sharing mail icons between MH-E and Gnus)

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> Those names make sense for Gnome, but not necessarily for Gnus.

Whenever we're creating names outside of the etc/images/gnus namespace,
we should be creating names that make sense for all of Emacs.

> It would be good to have feedback which kind of sort command are
> frequently used.

MH-E has mh-sort-folder which sorts by date. You can pass a prefix
argument which tells it to use mh-sortm-args in which case the sort is
custom. We'd use the sort-ascending icon.

If possible, it sounds like what would work well for Gnus is to use the
sort-ascending icon that doubles as a pull-down menu. A click would run
the default sort, while a drag would display a menu from which the user
can select one the various sort types.

-- 
Bill Wohler <wohler@newt.com>  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.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Icons for frequently used sort commands

[Reiner Steib]

On Tue, Feb 21 2006, Bill Wohler wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
>
>> Those names make sense for Gnome, but not necessarily for Gnus.
>
> Whenever we're creating names outside of the etc/images/gnus namespace,
> we should be creating names that make sense for all of Emacs.

Sure.

>> It would be good to have feedback which kind of sort command are
>> frequently used.
>
> MH-E has mh-sort-folder which sorts by date. You can pass a prefix
> argument which tells it to use mh-sortm-args in which case the sort is
> custom. 

Gnus uses the prefix to reverse the sort.

> We'd use the sort-ascending icon.

I'd suggest to add all 5 Gnome sort icons (in etc/images/).  In case
we need other icons for Gnus, we can add them (later) in
gnus/sort-whatever.  WDYT?

> If possible, it sounds like what would work well for Gnus is to use the
> sort-ascending icon that doubles as a pull-down menu. A click would run
> the default sort, while a drag would display a menu from which the user
> can select one the various sort types.

I'm not sure about "drag", but a menu on mouse-3 click would be fine
(like a context menu).  But this is not possible in Emacs 21 and 22,
(see [1]), but we can bind related actions to C-<tool bar icon> or
S-<tool bar icon>.  Alas I didn't know about this when designing the
customize interface for Gnus' menus so it's currently not supported (I
hope to add it later on).

Bye, Reiner.

[1]
,----[ http://thread.gmane.org/gmane.emacs.devel/50563 ]
| From: "Jan D." <jan.h.d@swipnet.se>
| Subject: Re: tool bar: C-... and S-... fail in GTK builds
| Newsgroups: gmane.emacs.devel
| Cc: emacs-devel@gnu.org
| Date: Wed, 15 Feb 2006 11:57:08 +0100 (CET)
| Message-ID: <200602151057.k1FAv8lR009084@coolsville.localdomain>
| Original-To: Juri Linkov <juri@jurta.org>
| 
| [...]
| 
| > Thanks!   Could you see how hard would be to implement mouse-2 and mouse-3
| > clicking on a tool bar item?  Is the main obstacle only in the format
| > of the menu keymap specification?
| 
| It is not hard on the C level.  we can put the button clicked in the code
| part of the struct input_event, and keyboard.c would then look at that
| also when constructing an event (currently code is ignored for tool bar
| events).
| 
| But I don't know to construct the Lisp event.  It could be done like
| for native scroll bars.  It is a mouse-event with a position that says
| scroll bar.  But the lisp code expects the position to contain a window,
| but for non-native tool bars (i.e. GTK) there is no window to put in
| there, just a frame.
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642

Re: Sharing mail icons between MH-E and Gnus

[Reiner Steib]

On Sun, Feb 19 2006, Bill Wohler wrote:

> I agree with your observation about mail-preview.xpm (that we should
> have a specific one.

I wrote:

  # We should have a mail-preview icon with an envelope as in
  # stock_mail-reply.

It should be similar to Gnus' preview.xpm, i.e. a magnifier on an
envelope.  The envelope should be like the one in stock_mail-reply
(and probably could be copied from there).  Maybe the magnifier can be
copied from one of the stock_zoom*.png files.

My Gimp skills are rather limited.  Any volunteer?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Adam Sjøgren]

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

On Mon, 20 Feb 2006 16:58:42 +0100, Reiner wrote:

> It should be similar to Gnus' preview.xpm, i.e. a magnifier on an
> envelope.  The envelope should be like the one in stock_mail-reply
> (and probably could be copied from there).  Maybe the magnifier can be
> copied from one of the stock_zoom*.png files.

> My Gimp skills are rather limited.  Any volunteer?

Here is an attempt at a preview- and a save email-icon.


  Best regards,

    Adam

-- 
 "Super heroes wear snow pants?"                              Adam Sjøgren
 "When there's snow out, they do!"                       asjo@koldfront.dk


[-- Attachment #2: stock_preview.png --]
[-- Type: image/png, Size: 1266 bytes --]

[-- Attachment #3: stock_save_email.png --]
[-- Type: image/png, Size: 1298 bytes --]

Re: Sharing mail icons between MH-E and Gnus

[Reiner Steib]

On Mon, Feb 20 2006, Adam Sjøgren wrote:

> Here is an attempt at a preview- and a save email-icon.

Thanks, Adam.  I like your icons.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Mon, Feb 20 2006, Adam Sj=F8gren wrote:
> 
> > Here is an attempt at a preview- and a save email-icon.
> 
> Thanks, Adam.  I like your icons.

Right, I forgot to say the same thing. Thanks very much (and you've
signed papers too--good).

-- 
Bill Wohler <wohler@newt.com>  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.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Reiner Steib]

On Tue, Feb 21 2006, Bill Wohler wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
[...]
>> Thanks, Adam.  I like your icons.
>
> Right, I forgot to say the same thing. Thanks very much (and you've
> signed papers too--good).

Some remarks:

Richard approved to use the Gnome icons without assignments [1].  I
don't know about the conditions for using other sources (of course we
can't use copyrighted material).  But if we have an assignment, it's
even better.  IIRC there's a dedicated assignment for "artwork" which
would be sufficient for icons, I think.

Adam's work basically was to combine existing Gnome stock icon into a
single icon (CMIIW please, Adam!).  We are on the save side if all
images used in such a combination icon are from Emacs or Gnome, I
think.

Some hours ago, I have committed the icons to Gnus trunk.  Below is a
list.  "#" means "not committed yet", e.g. because name is still under
discussion.  Bill, please let me know if you disagree with any of the
names.  If your interested, I can prepare a tarball with the new
images or you can check them out from CVS (gnus/etc/images/; see
www.gnus.org under "Distribution" for details on CVS access.  But
you'll get all old icons too).

--8<---------------cut here---------------start------------->8---
    connect.xpm
    contact.xpm
    delete.xpm
    describe.xpm
    disconnect.xpm
    exit.xpm
    lock-broken.xpm
    lock-ok.xpm
    lock.xpm
    refresh.xpm
    # sort-1-9.xpm
    # sort-a-z.xpm

    # gnus/flag-followup.xpm        stock_mail_flag_for_followup
    # gnus/mail-display.xpm         stock_message_display
    gnus/toggle-subscription.xpm

    mail/attach.xpm
    mail/compose.xpm
    mail/copy.xpm
    mail/forward.xpm
    mail/inbox.xpm
    mail/move.xpm
    mail/not-spam.xpm
    mail/outbox.xpm
    mail/reply-all.xpm
    mail/reply.xpm
    mail/save-draft.xpm
    mail/send.xpm
    mail/spam.xpm

The following icons were contributed by from Adam Sjøgren <asjo@koldfront.dk>:

    mail/preview.xpm (combining stock_mail and stock_zoom?)
    mail/save.xpm    (combining stock_mail, stock_save and stock_undo?)

The following icon is from AUCTeX:

    separator.xpm
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.

[1] See <http://article.gmane.org/gmane.emacs.devel/43394> and
    etc/images/README in Emacs CVS:

,----[ etc/images/README ]
| All of the following icons are not part of Emacs, but distributed and
| used by Emacs.
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

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

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> Some hours ago, I have committed the icons to Gnus trunk.

Thanks! You might consider floating the list, maybe my annotated version
for context, to emacs-devel. There's at least a couple of folks there
who might have some comments ;-). It's a history with this which is why
I wrote the following:

> On Tue, Feb 21 2006, Bill Wohler wrote:
> 
> > Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> >
> >> Those names make sense for Gnome, but not necessarily for Gnus.
> >
> > Whenever we're creating names outside of the etc/images/gnus namespace,
> > we should be creating names that make sense for all of Emacs.

> I'd suggest to add all 5 Gnome sort icons (in etc/images/).  In case
> we need other icons for Gnus, we can add them (later) in
> gnus/sort-whatever.  WDYT?

I'm cool with that. Folks (like MH-E) would use the icons directly. It
sounds like you (Gnus) folks would rename and retarget the icons for
slightly different uses. You'll, of course, have a
etc/images/gnus/README which describes that ;-).

> > If possible, it sounds like what would work well for Gnus is to use the
> > sort-ascending icon that doubles as a pull-down menu. A click would run
> > the default sort, while a drag would display a menu from which the user
> > can select one the various sort types.
> 
> I'm not sure about "drag", but a menu on mouse-3 click would be fine
> (like a context menu).

That would be kind of obscure, I think. I was thinking of those icons in
OutBreak (LookOut) for "Get Mail" that had little triangles. If you
click you get the default behavior (get all mail); if you press Mouse-1
and *hold* (or drag, as I said before), you get a menu to choose the one
mail source. However, check this out:


[-- Attachment #2: icon-menu.jpg --]
[-- Type: image/jpeg, Size: 11423 bytes --]

[-- Attachment #3: Type: text/plain, Size: 650 bytes --]


If you Mouse-1 on the v icon next to the New button, you get a menu of
things to create. That should be doable in both Emacs 21 and 22 I think.
I think that would be a fine solution until Emacs supports menuable
icons. Oddly enough, i couldn't find the v icon in $g. Can you?

p.s. I found $g/stock_draw-line-with-arrows.png that we could use in
place of our own widen.xpm if the other MH-E developers don't think we
should go with the un-zoom icon.

-- 
Bill Wohler <wohler@newt.com>  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.

Re: Sharing mail icons between MH-E and Gnus

[Adam Sjøgren]

On Wed, 22 Feb 2006 01:30:10 +0100, Reiner wrote:

> Adam's work basically was to combine existing Gnome stock icon into a
> single icon (CMIIW please, Adam!).

And a little scaling, yes.

>     mail/preview.xpm (combining stock_mail and stock_zoom?)

(Yes).

>     mail/save.xpm    (combining stock_mail, stock_save and stock_undo?)

(Actually it is stock_mail, stock_save and a corner of stock_convert :-))


  Best regards,

    Adam

-- 
 "So I was off a little bit, sue me."                         Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> Some hours ago, I have committed the icons to Gnus trunk.

Cool. When will they move to CVS Emacs?

>     mail/attach.xpm

Note that Kim, I think, had suggested that "attach" is general and asked
that I put it at the top level, instead of in mail. Indeed, the GNOME
name is stock_attach.png, not stock_mail-attach.png. So attach.xpm should
be at the tpo level.

>     # sort-1-9.xpm
>     # sort-a-z.xpm

I think you had decided to go with the GNOME names for now.

>     # gnus/flag-followup.xpm        stock_mail_flag_for_followup

OK (8.3 concerns?)

>     # gnus/mail-display.xpm         stock_message_display

8.3 concerns again? How about mail/display.xpm?

-- 
Bill Wohler <wohler@newt.com>  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.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Reiner Steib]

On Mon, Mar 06 2006, Bill Wohler wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:

[ Note that this was sent on Wed, 22 Feb 2006.  Maybe it didn't make
  it to you because of the lists.gnu.org delays. ]

>> Some hours ago, I have committed the icons to Gnus trunk.
>
> Cool. When will they move to CVS Emacs?

Well, Gnus 5.11 (Emacs CVS) and the stable branch (v5-10; 5.10.x
series) should be in sync.  The stable branch should only contain bug
fixes -- no new features.

My plan was to add the new icons (with the structure discussed above)
to the Gnus trunk and enable the new Gnome style tool bars by default.
This has been done in the meantime: The new icons are used by default
since 2006-03-01 (Emacs 22) or 2006-03-02 (Emacs 21) if the display
has enough colors (see `gmm-tool-bar-style').

If they work nicely and got some testing, I will re-consider whether
to put in it v5-10/Emacs or not.

But I think you can update MH-E independently of this.  We can
add/update all new images used by either MH-E or Gnus in Emacs CVS.

>>     mail/attach.xpm
>
> Note that Kim, I think, had suggested that "attach" is general and asked
> that I put it at the top level, instead of in mail. Indeed, the GNOME
> name is stock_attach.png, not stock_mail-attach.png. So attach.xpm should
> be at the tpo level.

Fine with me.  In <16231.1140316818@olgas.newt.com> you're suggestion
was $ei/mail/preview, but we can still change this to use $ei/preview.

>>     # sort-1-9.xpm
>>     # sort-a-z.xpm
>
> I think you had decided to go with the GNOME names for now.

"#" meant "not committed yet", e.g. because name is still under
discussion.   My last message WRT to sort*.xpm was:

,----[ Subject: Icons for frequently used sort commands ]
| > We'd use the sort-ascending icon.
| 
| I'd suggest to add all 5 Gnome sort icons (in etc/images/).  In case
| we need other icons for Gnus, we can add them (later) in
| gnus/sort-whatever.  WDYT?
`----

>>     # gnus/flag-followup.xpm        stock_mail_flag_for_followup
>
> OK (8.3 concerns?)
>
>>     # gnus/mail-display.xpm         stock_message_display
>
> 8.3 concerns again?

Yes, "flag-for-..." would not be 8.3 friendly.  For mail-display.xpm
there is no problem, AFAICS.

> How about mail/display.xpm?

Fine with me.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> >> Some hours ago, I have committed the icons to Gnus trunk.
> >
> > Cool. When will they move to CVS Emacs?
> 
> Well, Gnus 5.11 (Emacs CVS) and the stable branch (v5-10; 5.10.x
> series) should be in sync.  The stable branch should only contain bug
> fixes -- no new features.
> 
> My plan was to add the new icons (with the structure discussed above)
> to the Gnus trunk and enable the new Gnome style tool bars by default.
> This has been done in the meantime: The new icons are used by default
> since 2006-03-01 (Emacs 22) or 2006-03-02 (Emacs 21) if the display
> has enough colors (see `gmm-tool-bar-style').
> 
> If they work nicely and got some testing, I will re-consider whether
> to put in it v5-10/Emacs or not.
> 
> But I think you can update MH-E independently of this.  We can
> add/update all new images used by either MH-E or Gnus in Emacs CVS.

You might not be aware that we use Emacs' CVS repository, so if it's not
in CVS Emacs, it's not in MH-E.

I'm looking forward to seeing the images checked into CVS. I expect we
might have to make some image or image name tweaks or code tweaks in
MH-E once the images are checked in and we actually run with them, but
that's OK. For example:

> >>     mail/attach.xpm
> >
> > Note that Kim, I think, had suggested that "attach" is general and asked
> > that I put it at the top level, instead of in mail. Indeed, the GNOME
> > name is stock_attach.png, not stock_mail-attach.png. So attach.xpm should
> > be at the tpo level.
> 
> Fine with me.  In <16231.1140316818@olgas.newt.com> you're suggestion
> was $ei/mail/preview, but we can still change this to use $ei/preview.

s/preview/attach/.

Yes, my suggestion was in error. attach.* should be in etc/images, not
etc/images/mail.

> >>     # sort-1-9.xpm
> >>     # sort-a-z.xpm
> >
> > I think you had decided to go with the GNOME names for now.
> 
> "#" meant "not committed yet", e.g. because name is still under
> discussion.   My last message WRT to sort*.xpm was:
> 
> ,----[ Subject: Icons for frequently used sort commands ]
> | > We'd use the sort-ascending icon.
> | 
> | I'd suggest to add all 5 Gnome sort icons (in etc/images/).  In case
> | we need other icons for Gnus, we can add them (later) in
> | gnus/sort-whatever.  WDYT?
> `----

In 7109.1140584961@olgas.newt.com, I said, "I'm cool with that."

Thanks very much!

-- 
Bill Wohler <wohler@newt.com>  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.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Reiner Steib]

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

On Mon, Mar 06 2006, Bill Wohler wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
>> If they work nicely and got some testing, I will re-consider whether
>> to put in it v5-10/Emacs or not.
>> 
>> But I think you can update MH-E independently of this.  We can
>> add/update all new images used by either MH-E or Gnus in Emacs CVS.
>
> You might not be aware that we use Emacs' CVS repository, so if it's not
> in CVS Emacs, it's not in MH-E.

I was aware of this. :-) Let me rephrase: We should suggest (or
announce?) on emacs-devel that we'd like to add or update those icons
in Emacs CVS.  "Those icons" = all icons that will be used either in
MH-E or in Gnus (after some more testing in Gnus CVS) or both.

> I'm looking forward to seeing the images checked into CVS. I expect we
> might have to make some image or image name tweaks or code tweaks in
> MH-E once the images are checked in and we actually run with them, but
> that's OK.

If you would like to present our suggestions on emacs-devel now,
please go ahead.

Maybe the list in gnus/etc/image/README is useful for this.  I'll
attach it to this message (with some changes which I haven't committed
yet: sort*.xpm, attach.xpm).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

[-- Attachment #2: README --]
[-- Type: text/plain, Size: 1805 bytes --]

The following icons are from GNOME 2.6:

    attach.xpm (stock_attach)
    connect.xpm (stock_connect)
    contact.xpm (stock_contact)
    delete.xpm (stock_delete)
    describe.xpm (stock_properties)
    disconnect.xpm (stock_disconnect)
    exit.xpm (stock_exit)
    lock-broken.xpm (stock_lock_broken)
    lock-ok.xpm (stock_lock_ok)
    lock.xpm (stock_lock)
    next-page.xpm (stock_next-page)
    refresh.xpm (stock_refresh)
    sort-ascending (stock_sort-ascending)
    sort-column-ascending (stock_sort-column-ascending)
    sort-criteria (stock_sort-criteria)
    sort-descending (stock_sort-descending)
    sort-row-ascending (stock_sort-row-ascending)

    gnus/toggle-subscription.xpm (stock_task-recurring)

    mail/compose.xpm (stock_mail-compose)
    mail/copy.xpm (stock_mail-copy)
    mail/forward.xpm (stock_mail-forward)
    mail/inbox.xpm (stock_inbox)
    mail/move.xpm (stock_mail-move)
    mail/not-spam.xpm (stock_not-spam)
    mail/outbox.xpm (stock_outbox)
    mail/reply-all.xpm (stock_mail-reply-to-all)
    mail/reply.xpm (stock_mail-reply)
    mail/save-draft.xpm (stock_mail-handling)
    mail/send.xpm (stock_mail-send)
    mail/spam.xpm (stock_spam)


The following icons were contributed by Adam Sjøgren <asjo@koldfront.dk>:

    mail/preview.xpm (combining stock_mail and stock_zoom)
    mail/save.xpm    (combining stock_mail, stock_save and stock_convert) 


The following icon is from AUCTeX:

    separator.xpm (sep.xpm)


The folling icon are duplicated from Emacs 22.  They are either not present in
Emacs 21 or look different there.

    cancel.xpm
    copy.xpm
    diropen.xpm
    help.xpm
    left-arrow.xpm
    paste.xpm
    print.xpm
    redo.xpm
    right-arrow.xpm
    save.xpm
    search.xpm

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Mon, Mar 06 2006, Bill Wohler wrote:
> 
> > Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> >> If they work nicely and got some testing, I will re-consider whether
> >> to put in it v5-10/Emacs or not.
> >> 
> >> But I think you can update MH-E independently of this.  We can
> >> add/update all new images used by either MH-E or Gnus in Emacs CVS.
> >
> > You might not be aware that we use Emacs' CVS repository, so if it's not
> > in CVS Emacs, it's not in MH-E.
> 
> I was aware of this. :-) 

I must of misunderstood, sorry.

>                          Let me rephrase: We should suggest (or
> announce?) on emacs-devel that we'd like to add or update those icons
> in Emacs CVS.  "Those icons" = all icons that will be used either in
> MH-E or in Gnus (after some more testing in Gnus CVS) or both.

Yup.

> > I'm looking forward to seeing the images checked into CVS. I expect we
> > might have to make some image or image name tweaks or code tweaks in
> > MH-E once the images are checked in and we actually run with them, but
> > that's OK.
> 
> If you would like to present our suggestions on emacs-devel now,
> please go ahead.
>
> Maybe the list in gnus/etc/image/README is useful for this.  I'll
> attach it to this message (with some changes which I haven't committed
> yet: sort*.xpm, attach.xpm).

If you wish, I'd do that now.

Thanks for attaching the README as it summarizes our dialog. Note that
the sort* images lack a .xpm suffix.

-- 
Bill Wohler <wohler@newt.com>  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.

Re: Sharing mail icons between MH-E and Gnus

[Reiner Steib]

On Sun, Feb 19 2006, Bill Wohler wrote:

> mh-image-load-path has morphed a bit in the past week. I have yet to
> give some thought to generalizing it.

I modified MH-E's new `mh-image-load-path' a bit to use it in Gnus.  I
didn't do much testing but to avoid duplicate work, I'll post it here.
So please consider it as a draft.

I don't like that `mh-image-load-path' changes the variables
`load-path' or `image-load-path'.  Assume you have unbundled versions
of Gnus and MH-E installed using Emacs 21.  Which path should win, if
we both use the same variable?

`mm-image-load-path' doesn't modify anything.  It just returns a new
path.  Then it was typically used like this:

             (let ((load-path (mm-image-load-path)))
               (setup-the-toolbar-...))

Catering for Emacs 22 (`image-load-path') and Emacs 21 we can use this
in Gnus...

      (let ((load-path (gmm-image-load-path "message" nil 'load-path))
	    (image-load-path
	     (gmm-image-load-path "message" nil 'image-load-path)))
	    (gmm-tool-bar-from-list message-tool-bar
				    message-tool-bar-zap-list
				    'message-mode-map))

--8<---------------cut here---------------start------------->8---
;; From MH-E without modifications:

(defmacro gmm-defun-compat (name function arg-list &rest body)
  "Create function NAME.
If FUNCTION exists, then NAME becomes an alias for FUNCTION.
Otherwise, create function NAME with ARG-LIST and BODY."
  (let ((defined-p (fboundp function)))
    (if defined-p
        `(defalias ',name ',function)
      `(defun ,name ,arg-list ,@body))))

(gmm-defun-compat gmm-image-search-load-path
  image-search-load-path (file &optional path)
  "Emacs 21 and XEmacs don't have `image-search-load-path'.
This function returns nil on those systems."
  nil)

;; From MH-E with modifications:

(defvar gmm-image-load-path nil
  "Directory where images for MH-E are found.
See function `gmm-image-load-path'.")

;; (defvar image-load-path)
(defun gmm-image-load-path (library &optional image path)
  "Return a suitable search path for images of LIBRARY.

Images for LIBRARY are found in \"../../etc/images\" relative to
the files in \"lisp/LIBRARY\", in `image-load-path', or in
`load-path'.

This function returns value of `load-path' augmented with the
path to IMAGE.  If PATH is given, it is used instead of
`load-path'."
  (unless library (error "No library specified."))
  (unless image
    (setq image ;; DWIM
	  (cond ((string-match "^gnus\\>\\|^message" library)
		 "describe.xpm")
		((string-match "^mh-" library)
		 "mh-logo.xpm")
		(t ;; Which icon should be used here?
		 "contact.xpm"))))
  (cond (gmm-image-load-path) ;; User setting exists.
	((let (gmm-library-name) ;; Try relative setting
	   ;; First, find library in the load-path.
	   (setq gmm-library-name (locate-library library))
	   (if (not gmm-library-name)
	       (error "Cannot find library `%s' in load-path" library))
	   ;; And then set gmm-image-load-path relative to that.
	   (setq gmm-image-load-path
		 (expand-file-name (concat
				    (file-name-directory gmm-library-name)
				    "../../etc/images")))
	   (file-exists-p (expand-file-name image gmm-image-load-path))))
	((gmm-image-search-load-path image)
	 ;; Images in image-load-path.
	 (setq gmm-image-load-path
	       (file-name-directory (gmm-image-search-load-path image))))
	((locate-library image)
	 ;; Images in load-path.
	 (setq gmm-image-load-path
	       (file-name-directory (locate-library image)))))
  ;;
  (unless (file-exists-p gmm-image-load-path)
    (error "Directory `%s' in gmm-image-load-path does not exist"
	     gmm-image-load-path))
  (unless (file-exists-p (expand-file-name image gmm-image-load-path))
    (error "Directory `%s' in gmm-image-load-path does not contain image `%s'."
	   gmm-image-load-path image))
  ;; Return augmented `image-load-path' or `load-path'.
  (cond ((and path (symbolp path))
	 (nconc (list gmm-image-load-path) (symbol-value path)))
	(t
	 (nconc (list gmm-image-load-path) load-path))))
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> I don't like that `mh-image-load-path' changes the variables
> `load-path' or `image-load-path'.

I'm not sure I agree. Taking this argument to an extreme conclusion,
both load-path and image-load-path would always be empty. Leaving the
path to our images on these paths makes it more clear to the user (or
developer) where the images came from, if that needs to be discovered.
It's also conceivable that using a temporary load-path/image-load-path
might invalidate image caching schemes.

>                                    Assume you have unbundled versions
> of Gnus and MH-E installed using Emacs 21. Which path should win, if
> we both use the same variable?

And what if the user adds his own images to image-load-path (if he
defined a theme, if you will) and expects to see his images rather than
yours? Since you didn't leave your path on the image-load-path, he would
be confused since he wouldn't see where they came from.

Hmmm, this argues that we would want prepend the default Emacs path
(since a newer Gnus/MH-E package might have newer images than the one
distributed with an old version of Emacs) and append to any user-defined
paths (since the user is always right). Is that possible?

At any rate, since we're coordinating now, those icons will probably be
the same anyway, so I don't think that this will be much of a problem.

> (defmacro gmm-defun-compat (name function arg-list &rest body)

We've borrowed so much from Gnus, I'd be tickled pink if Gnus borrowed
from MH-E ;-).

> (defun gmm-image-load-path (library &optional image path)

For the generalized function, we might want to make IMAGE non-optional
so that we don't have MH-E and Gnus icons in the code.

>   ;; Return augmented `image-load-path' or `load-path'.
>   (cond ((and path (symbolp path))
> 	 (nconc (list gmm-image-load-path) (symbol-value path)))
> 	(t
> 	 (nconc (list gmm-image-load-path) load-path))))

Now it's my turn not to like the code ;-). This doesn't use
image-load-path if it exists. It can add the image directory even if it
already exists on path.

I was going to argue against the path argument, but it would be
consistent with image-search-load-path. I think it's a good idea,
however, to return the modified list.

I guess the big question is whether to modify image-load-path
(load-path) or not. It would be good for a few others to weigh in. It
would be good to solicit opinions from the folks on emacs-devel too.
I'll do that.

-- 
Bill Wohler <wohler@newt.com>  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.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Reiner Steib]

On Mon, Feb 20 2006, Bill Wohler wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
>
>> I don't like that `mh-image-load-path' changes the variables
>> `load-path' or `image-load-path'.
>
> I'm not sure I agree. Taking this argument to an extreme conclusion,
> both load-path and image-load-path would always be empty. Leaving the
> path to our images on these paths makes it more clear to the user (or
> developer) where the images came from, if that needs to be discovered.

`C-h v tool-bar RET' displays stuff like this for me:

 (Preview menu-item "Preview" mml-preview
	  ([3 13 80]
	   . "  (C-c RET P)")
	  :image
	  (image :type xpm :file "[...]/emacs/etc/images/mail/preview.xpm"))

> It's also conceivable that using a temporary load-path/image-load-path
> might invalidate image caching schemes.

AFAICS, `image.el' stores the full path.  See above.

> And what if the user adds his own images to image-load-path (if he
> defined a theme, if you will) and expects to see his images rather than
> yours? Since you didn't leave your path on the image-load-path, he would
> be confused since he wouldn't see where they came from.

I though that the variable `gmm-image-load-path' (or
mh-image-load-path) is intended for this.

BTW, if you/we call it *-path it should be a list (else: *-directory).

> Hmmm, this argues that we would want prepend the default Emacs path
> (since a newer Gnus/MH-E package might have newer images than the one
> distributed with an old version of Emacs) and append to any user-defined
> paths (since the user is always right). Is that possible?

- We (or `image.el') could use an additional `*-user-image-load-path'
  and always prepend this.

- We could check if `image-load-path' has it's default value...  Hm
  stop... `image-load-path' isn't customizable.
  I've suggested a patch to do this in September 2005 on emacs-devel:
  <http://article.gmane.org/gmane.emacs.devel/43198>.  There was
  neither positive or negative feedback.

> At any rate, since we're coordinating now, those icons will probably be
> the same anyway, so I don't think that this will be much of a problem.

(Gnus and MH-E were just examples here.)

>> (defmacro gmm-defun-compat (name function arg-list &rest body)
>
> We've borrowed so much from Gnus, I'd be tickled pink if Gnus borrowed
> from MH-E ;-).

:-)

>> (defun gmm-image-load-path (library &optional image path)
>
> For the generalized function, we might want to make IMAGE non-optional
> so that we don't have MH-E and Gnus icons in the code.

ACK.  That was just for my laziness.

>>   ;; Return augmented `image-load-path' or `load-path'.
>>   (cond ((and path (symbolp path))
>> 	 (nconc (list gmm-image-load-path) (symbol-value path)))
>> 	(t
>> 	 (nconc (list gmm-image-load-path) load-path))))
>
> Now it's my turn not to like the code ;-).  This doesn't use
> image-load-path if it exists.

You need to use (gmm-image-load-path "message" nil 'image-load-path)
for this as I did the example in my previous article:

      (let ((load-path (gmm-image-load-path "message" nil 'load-path))
	    (image-load-path
	     (gmm-image-load-path "message" nil 'image-load-path)))
	    (gmm-tool-bar-from-list message-tool-bar
				    message-tool-bar-zap-list
				    'message-mode-map))

> It can add the image directory even if it already exists on path.

A minor issue, I think.  But the following should remove the
duplicates:

  ;; Return augmented `image-load-path' or `load-path'.
  (cond ((and path (symbolp path))
	 (nconc (list gmm-image-load-path)
		(delete gmm-image-load-path (if (boundp path)
						(symbol-value path)
					      nil))))
	(t
	 (nconc (list gmm-image-load-path)
		(delete gmm-image-load-path load-path)))))

Without "(boundp path)" it won't work in Emacs 21.  I didn't test this
yesterday.

> I guess the big question is whether to modify image-load-path
> (load-path) or not. It would be good for a few others to weigh in. It
> would be good to solicit opinions from the folks on emacs-devel too.
> I'll do that.

I've just checked in `gmm-image-load-path' in `gmm-utils.el' (Gnus
trunk) marked with a "Subject to change" warning.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Sharing mail icons between MH-E and Gnus

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Mon, Feb 20 2006, Bill Wohler wrote:
> 
> > Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> >
> >> I don't like that `mh-image-load-path' changes the variables
> >> `load-path' or `image-load-path'.
> >
> > I'm not sure I agree. Taking this argument to an extreme conclusion,
> > both load-path and image-load-path would always be empty. Leaving the
> > path to our images on these paths makes it more clear to the user (or
> > developer) where the images came from, if that needs to be discovered.
> 
> `C-h v tool-bar RET' displays stuff like this for me:
> 
>  (Preview menu-item "Preview" mml-preview
> 	  ([3 13 80]
> 	   . "  (C-c RET P)")
> 	  :image
> 	  (image :type xpm :file "[...]/emacs/etc/images/mail/preview.xpm"))

Cool!

> > And what if the user adds his own images to image-load-path (if he
> > defined a theme, if you will) and expects to see his images rather than
> > yours? Since you didn't leave your path on the image-load-path, he would
> > be confused since he wouldn't see where they came from.
> 
> I though that the variable `gmm-image-load-path' (or
> mh-image-load-path) is intended for this.
> 
> BTW, if you/we call it *-path it should be a list (else: *-directory).

Thanks. Good thinking.

> > Hmmm, this argues that we would want prepend the default Emacs path
> > (since a newer Gnus/MH-E package might have newer images than the one
> > distributed with an old version of Emacs) and append to any user-defined
> > paths (since the user is always right). Is that possible?
> 
> - We (or `image.el') could use an additional `*-user-image-load-path'
>   and always prepend this.

Hmmm, that might work.

-- 
Bill Wohler <wohler@newt.com>  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.