* 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) [not found] ` <28928.1129483226@olgas.newt.com> @ 2005-10-17 13:27 ` Reiner Steib 2005-10-17 15:32 ` Sharing mail icons between MH-E and Gnus Bill Wohler 0 siblings, 1 reply; 28+ messages in thread From: Reiner Steib @ 2005-10-17 13:27 UTC (permalink / raw) [ 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2005-10-17 13:27 ` 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 @ 2005-10-17 15:32 ` Bill Wohler 2006-01-19 21:37 ` Reiner Steib 0 siblings, 1 reply; 28+ messages in thread From: Bill Wohler @ 2005-10-17 15:32 UTC (permalink / raw) Cc: Ding List, mh-e-devel, emacs-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2005-10-17 15:32 ` Sharing mail icons between MH-E and Gnus Bill Wohler @ 2006-01-19 21:37 ` Reiner Steib 2006-01-23 17:46 ` Bill Wohler 2006-02-19 2:40 ` Bill Wohler 0 siblings, 2 replies; 28+ messages in thread From: Reiner Steib @ 2006-01-19 21:37 UTC (permalink / raw) Cc: mh-e-devel 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-01-19 21:37 ` Reiner Steib @ 2006-01-23 17:46 ` Bill Wohler 2006-02-19 2:40 ` Bill Wohler 1 sibling, 0 replies; 28+ messages in thread From: Bill Wohler @ 2006-01-23 17:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-01-19 21:37 ` Reiner Steib 2006-01-23 17:46 ` Bill Wohler @ 2006-02-19 2:40 ` Bill Wohler 2006-02-20 1:26 ` Reiner Steib ` (2 more replies) 1 sibling, 3 replies; 28+ messages in thread From: Bill Wohler @ 2006-02-19 2:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-19 2:40 ` Bill Wohler @ 2006-02-20 1:26 ` Reiner Steib 2006-02-20 19:57 ` Bill Wohler 2006-02-20 15:58 ` Sharing mail icons between MH-E and Gnus Reiner Steib 2006-02-20 21:19 ` Reiner Steib 2 siblings, 1 reply; 28+ messages in thread From: Reiner Steib @ 2006-02-20 1:26 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-20 1:26 ` Reiner Steib @ 2006-02-20 19:57 ` Bill Wohler 2006-02-20 22:04 ` Reiner Steib 0 siblings, 1 reply; 28+ messages in thread From: Bill Wohler @ 2006-02-20 19:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-20 19:57 ` Bill Wohler @ 2006-02-20 22:04 ` Reiner Steib 2006-02-21 0:30 ` Bill Wohler 0 siblings, 1 reply; 28+ messages in thread From: Reiner Steib @ 2006-02-20 22:04 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-20 22:04 ` Reiner Steib @ 2006-02-21 0:30 ` Bill Wohler 2006-02-21 11:37 ` Icons for frequently used sort commands (was: Sharing mail icons between MH-E and Gnus) Reiner Steib 0 siblings, 1 reply; 28+ messages in thread From: Bill Wohler @ 2006-02-21 0:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Icons for frequently used sort commands (was: Sharing mail icons between MH-E and Gnus) 2006-02-21 0:30 ` Bill Wohler @ 2006-02-21 11:37 ` Reiner Steib 2006-02-21 22:22 ` Bill Wohler 0 siblings, 1 reply; 28+ messages in thread From: Reiner Steib @ 2006-02-21 11:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Icons for frequently used sort commands (was: Sharing mail icons between MH-E and Gnus) 2006-02-21 11:37 ` Icons for frequently used sort commands (was: Sharing mail icons between MH-E and Gnus) Reiner Steib @ 2006-02-21 22:22 ` Bill Wohler 2006-02-22 0:30 ` Icons for frequently used sort commands Reiner Steib 0 siblings, 1 reply; 28+ messages in thread From: Bill Wohler @ 2006-02-21 22:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Icons for frequently used sort commands 2006-02-21 22:22 ` Bill Wohler @ 2006-02-22 0:30 ` Reiner Steib 0 siblings, 0 replies; 28+ messages in thread From: Reiner Steib @ 2006-02-22 0:30 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-19 2:40 ` Bill Wohler 2006-02-20 1:26 ` Reiner Steib @ 2006-02-20 15:58 ` Reiner Steib 2006-02-20 21:23 ` Adam Sjøgren 2006-02-20 21:19 ` Reiner Steib 2 siblings, 1 reply; 28+ messages in thread From: Reiner Steib @ 2006-02-20 15:58 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-20 15:58 ` Sharing mail icons between MH-E and Gnus Reiner Steib @ 2006-02-20 21:23 ` Adam Sjøgren 2006-02-21 11:30 ` Reiner Steib 0 siblings, 1 reply; 28+ messages in thread From: Adam Sjøgren @ 2006-02-20 21:23 UTC (permalink / raw) Cc: mh-e-devel [-- 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 --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-20 21:23 ` Adam Sjøgren @ 2006-02-21 11:30 ` Reiner Steib 2006-02-21 22:11 ` Bill Wohler 0 siblings, 1 reply; 28+ messages in thread From: Reiner Steib @ 2006-02-21 11:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-21 11:30 ` Reiner Steib @ 2006-02-21 22:11 ` Bill Wohler 2006-02-22 0:30 ` Reiner Steib 0 siblings, 1 reply; 28+ messages in thread From: Bill Wohler @ 2006-02-21 22:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-21 22:11 ` Bill Wohler @ 2006-02-22 0:30 ` Reiner Steib 2006-02-22 5:09 ` Bill Wohler ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Reiner Steib @ 2006-02-22 0:30 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-22 0:30 ` Reiner Steib @ 2006-02-22 5:09 ` Bill Wohler 2006-02-22 6:43 ` Adam Sjøgren 2006-03-06 16:46 ` Bill Wohler 2 siblings, 0 replies; 28+ messages in thread From: Bill Wohler @ 2006-02-22 5:09 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-22 0:30 ` Reiner Steib 2006-02-22 5:09 ` Bill Wohler @ 2006-02-22 6:43 ` Adam Sjøgren 2006-03-06 16:46 ` Bill Wohler 2 siblings, 0 replies; 28+ messages in thread From: Adam Sjøgren @ 2006-02-22 6:43 UTC (permalink / raw) Cc: mh-e-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-22 0:30 ` Reiner Steib 2006-02-22 5:09 ` Bill Wohler 2006-02-22 6:43 ` Adam Sjøgren @ 2006-03-06 16:46 ` Bill Wohler 2006-03-06 19:15 ` Reiner Steib 2 siblings, 1 reply; 28+ messages in thread From: Bill Wohler @ 2006-03-06 16:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-03-06 16:46 ` Bill Wohler @ 2006-03-06 19:15 ` Reiner Steib 2006-03-06 21:40 ` Bill Wohler 0 siblings, 1 reply; 28+ messages in thread From: Reiner Steib @ 2006-03-06 19:15 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-03-06 19:15 ` Reiner Steib @ 2006-03-06 21:40 ` Bill Wohler 2006-03-06 23:21 ` Reiner Steib 0 siblings, 1 reply; 28+ messages in thread From: Bill Wohler @ 2006-03-06 21:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-03-06 21:40 ` Bill Wohler @ 2006-03-06 23:21 ` Reiner Steib 2006-03-07 0:06 ` Bill Wohler 0 siblings, 1 reply; 28+ messages in thread From: Reiner Steib @ 2006-03-06 23:21 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-03-06 23:21 ` Reiner Steib @ 2006-03-07 0:06 ` Bill Wohler 0 siblings, 0 replies; 28+ messages in thread From: Bill Wohler @ 2006-03-07 0:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-19 2:40 ` Bill Wohler 2006-02-20 1:26 ` Reiner Steib 2006-02-20 15:58 ` Sharing mail icons between MH-E and Gnus Reiner Steib @ 2006-02-20 21:19 ` Reiner Steib 2006-02-20 22:53 ` Bill Wohler 2 siblings, 1 reply; 28+ messages in thread From: Reiner Steib @ 2006-02-20 21:19 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-20 21:19 ` Reiner Steib @ 2006-02-20 22:53 ` Bill Wohler 2006-02-21 21:22 ` Reiner Steib 0 siblings, 1 reply; 28+ messages in thread From: Bill Wohler @ 2006-02-20 22:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-20 22:53 ` Bill Wohler @ 2006-02-21 21:22 ` Reiner Steib 2006-02-21 22:29 ` Bill Wohler 0 siblings, 1 reply; 28+ messages in thread From: Reiner Steib @ 2006-02-21 21:22 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Sharing mail icons between MH-E and Gnus 2006-02-21 21:22 ` Reiner Steib @ 2006-02-21 22:29 ` Bill Wohler 0 siblings, 0 replies; 28+ messages in thread From: Bill Wohler @ 2006-02-21 22:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2006-03-07 0:06 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <E1EQxwu-00028T-D0@mail.sourceforge.net> [not found] ` <28928.1129483226@olgas.newt.com> 2005-10-17 13:27 ` 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 2005-10-17 15:32 ` Sharing mail icons between MH-E and Gnus Bill Wohler 2006-01-19 21:37 ` Reiner Steib 2006-01-23 17:46 ` Bill Wohler 2006-02-19 2:40 ` Bill Wohler 2006-02-20 1:26 ` Reiner Steib 2006-02-20 19:57 ` Bill Wohler 2006-02-20 22:04 ` Reiner Steib 2006-02-21 0:30 ` Bill Wohler 2006-02-21 11:37 ` Icons for frequently used sort commands (was: Sharing mail icons between MH-E and Gnus) Reiner Steib 2006-02-21 22:22 ` Bill Wohler 2006-02-22 0:30 ` Icons for frequently used sort commands Reiner Steib 2006-02-20 15:58 ` Sharing mail icons between MH-E and Gnus Reiner Steib 2006-02-20 21:23 ` Adam Sjøgren 2006-02-21 11:30 ` Reiner Steib 2006-02-21 22:11 ` Bill Wohler 2006-02-22 0:30 ` Reiner Steib 2006-02-22 5:09 ` Bill Wohler 2006-02-22 6:43 ` Adam Sjøgren 2006-03-06 16:46 ` Bill Wohler 2006-03-06 19:15 ` Reiner Steib 2006-03-06 21:40 ` Bill Wohler 2006-03-06 23:21 ` Reiner Steib 2006-03-07 0:06 ` Bill Wohler 2006-02-20 21:19 ` Reiner Steib 2006-02-20 22:53 ` Bill Wohler 2006-02-21 21:22 ` Reiner Steib 2006-02-21 22:29 ` Bill Wohler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).