Re: Sharing mail icons between MH-E and Gnus

[Reiner Steib <reinersteib+gmane@imap.cc>]

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