Re: Shall we use etc/images more?

[Bill Wohler]

Thanks much for the quick feedback.

Kim F. Storm <address@hidden> wrote:

> >     
> >     etc/images/mail/alias -- adds the current sender to your alias file
> 
> Add XX item to YY list/file.

Yes and no. If you're add X, Y, and Z items to XX, YY, and ZZ lists,
then having three identical icons to do those things isn't terribly
useful. I don't think I can buy this suggestion quite yet.

> >     etc/images/mail/rescan -- updates the message listing
> 
> Refresh

Like in a browser. Hmmm. That might work. What does the MH-E gang think
about replacing the cabinet icon with a more well-known refresh icon
(two arrows chasing the other's tail) and renaming rescan (the icon) to
refresh?

> >     etc/images/mail/show -- display the current message
> 
> Display current ITEM

Yes. I think our icon would work for dired even.

> >     etc/images/mail/widen -- removes a view restriction
> 
> Widen -- in general

Yes.

> > In the long term, I think we should modify find-image to use the
> > algorithm in mm-image-load-path instead of using just data-directory.
> 
> That's a good suggestion.

Thanks. However, I'm not entirely sure about this now since find-image
would have to keep track of when it updated the load-path and re-run the
algorithm whenever it detects that load-path changes, which would be
kind of a pain. I think I liked your suggestion about image-load-path,
although one problem with this that just occurred to me is that it would
add a little complexity to the user's environment and may not have the
benefit to counter that complexity. So, perhaps RMS is right.

Richard M. Stallman <address@hidden> wrote:

>     I don't remember why reply2
>     went into the mail directory, but we added the -2 suffix to avoid
>     potential conflicts with Gnus.
> 
> If Gnus and MH-E both want an icon for replies, shouldn't they both
> use the same one?

Yes.

> This makes sense, except that having a subdirectory mh-e just to
> contain one file is pointless.  It would be better to use
> etc/images/mh-logo for that.

My thinking was that all icons at the top level are general icons that
could be used in any package. Icons that are only relevant to a single
package (or "virtual" package as in "mail") should be in a sub-directory
with the same name as that package. Thus, the directory serves not only
to reduce clutter, but to make it easier for someone to find an icon by
organizing them in groups rather than in a jumbled collection at the top
level. Does this sound like a good reason to you? On the other hand,
putting all of the application-identification icons (like mh-logo) in a
single directory makes it easier to find the one you want if you're
binding a desktop icon to your Emacs app (although the Gnome project
puts them in an "apps" directory which I could start). Given the size of
MH-E, it's also very possible that we may add more specific icons in the
future. I could go any of three ways as I've argued all sides ;-).

Should I put the mh-logo image in the top-level, in "mh-e", or in "apps"?

>     In the long term, I think we should modify find-image to use the
>     algorithm in mm-image-load-path instead of using just data-directory.
> 
> I think we should not do either of these; instead, we should do
> what you've suggested here.
> 
>     Gnus adds etc/images/gnus to the load-path so that it can refer to the
>     images directly like "exit-gnus" instead of "gnus/exit-gnus". 

By "here" I'm assuming that you think that the MH-E package should
modify the load-path as Gnus does?

>                                                                   I think
>     I'd prefer to specify the images explicitly as in "execute" or
>     "mail/reply"
> 
> I agree.

OK, I will do that.

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