Customizable tool bars

Customizable tool bars

[Reiner Steib]

Hi,

I've committed a customizable tool bar interface for message mode
(Emacs only, not XEmacs).  There should not be any user-visible
difference yet, because I haven't committed the new icons yet[1].  But
the code and `M-x customize-apropos RET message-tool-bar- RET'[2]
should give you an idea how it is supposed to work.  Similar changes
for the group and summary buffers in Gnus will follow.

Bye, Reiner.

[1] Not committed yet, because I'm hoping for feedback on my
    suggestions (<news:v9lkxbyk49.fsf@marauder.physik.uni-ulm.de>,
    <http://thread.gmane.org/gmane.emacs.gnus.general/61719>).

[2] You probably need to restart Emacs after customizing.  I forgot to
    add a setter function to the defcustoms.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Customizable tool bars

[Reiner Steib]

On Fri, Jan 20 2006, Reiner Steib wrote:

> I've committed a customizable tool bar interface for message mode
> (Emacs only, not XEmacs).  There should not be any user-visible
> difference yet, because I haven't committed the new icons yet[1].  But
> the code and `M-x customize-apropos RET message-tool-bar- RET'[2]
> should give you an idea how it is supposed to work.  Similar changes
> for the group and summary buffers in Gnus will follow.

Done.

If you'd like to try the new icons, unpack new-gnus-icons.tar.gz [3],
build (and optionally install) Gnus.  After restarting Gnus, customize
the variables message-tool-bar, gnus-group-tool-bar and
gnus-summary-tool-bar to GNOME style (M-x customize-apropos RET
-tool-bar$ RET) or use the following code:

(progn
  (setq message-tool-bar 'message-tool-bar-gnome
	gnus-group-tool-bar 'gnus-group-tool-bar-gnome
	gnus-summary-tool-bar 'gnus-summary-tool-bar-gnome)
  (message-tool-bar-update)
  (gnus-group-tool-bar-update)
  (gnus-summary-tool-bar-update))

> [1] Not committed yet, because I'm hoping for feedback on my
>     suggestions (<news:v9lkxbyk49.fsf@marauder.physik.uni-ulm.de>,
>     <http://thread.gmane.org/gmane.emacs.gnus.general/61719>).
>
> [2] You probably need to restart Emacs after customizing.  I forgot to
>     add a setter function to the defcustoms.

Fixed.

Bye, Reiner.

[3] http://theotp1.physik.uni-ulm.de/~ste/comp/emacs/gnus/tool-bar/new-gnus-icons.tar.gz
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Customizable tool bars

[Katsumi Yamaoka]

Currently, it makes XEmacs be unable to start No Gnus.  For the
workaround, I added the following form to the ~/.gnus.el file.

(when (featurep 'xemacs)
  (eval-after-load "gnus-group"
    '(defalias 'gnus-group-make-tool-bar 'ignore))
  (eval-after-load "gnus-sum"
    '(defalias 'gnus-summary-make-tool-bar 'ignore)))

>>>>> In <v9k6coqn13.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

> On Fri, Jan 20 2006, Reiner Steib wrote:

>> I've committed a customizable tool bar interface for message mode
>> (Emacs only, not XEmacs).

BTW, the following two lines appear in the terminal emulator
whenever I start XEmacs in the terminal even if I use the
-vanilla option.

Loading gmm-utils...
Loading gmm-utils...done

Does anyone know why?  They are entered in the beginning of the
" *Message-Log*" buffer as well.

Re: Customizable tool bars

[Steve Youngs]

[-- Attachment #1.1: Type: text/plain, Size: 1135 bytes --]

* Katsumi Yamaoka <yamaoka@jpl.org> writes:

  > Currently, it makes XEmacs be unable to start No Gnus.  For the
  > workaround, I added the following form to the ~/.gnus.el file.

  > (when (featurep 'xemacs)
  >   (eval-after-load "gnus-group"
  >     '(defalias 'gnus-group-make-tool-bar 'ignore))
  >   (eval-after-load "gnus-sum"
  >     '(defalias 'gnus-summary-make-tool-bar 'ignore)))

Good to know, thanks.

  >>>>>> In <v9k6coqn13.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

  >> On Fri, Jan 20 2006, Reiner Steib wrote:

  >>> I've committed a customizable tool bar interface for message mode
  >>> (Emacs only, not XEmacs).

  > BTW, the following two lines appear in the terminal emulator
  > whenever I start XEmacs in the terminal even if I use the
  > -vanilla option.

  > Loading gmm-utils...
  > Loading gmm-utils...done

  > Does anyone know why?

It's from over-aggressive autoloading.  And the reason you still see
the problem with -vanilla is because -vanilla still loads the
auto-autoloads.el files.  To _not_ load those you need -no-autoloads.

Here's a patch to fix the spurious output to stdout...


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: Type: text/x-patch, Size: 890 bytes --]


Index: gmm-utils.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gmm-utils.el,v
retrieving revision 7.6
diff -u -p -u -r7.6 gmm-utils.el
--- gmm-utils.el	24 Jan 2006 16:37:36 -0000	7.6
+++ gmm-utils.el	26 Jan 2006 01:34:01 -0000
@@ -110,7 +110,6 @@ This is copy of the `lazy' widget in Ema
 ;; version will provide customizable tool bar buttons using a different
 ;; interface.
 
-;;;###autoload
 (define-widget 'gmm-tool-bar-item (if (gmm-widget-p 'lazy) 'lazy 'gmm-lazy)
   "Tool bar list item."
   :tag "Tool bar item"
@@ -130,7 +129,6 @@ This is copy of the `lazy' widget in Ema
 		(const :tag "No map")
 		(plist :inline t :tag "Properties"))))
 
-;;;###autoload
 (define-widget 'gmm-tool-bar-zap-list (if (gmm-widget-p 'lazy) 'lazy 'gmm-lazy)
   "Tool bar zap list."
   :tag "Tool bar zap list"


[-- Attachment #1.3: Type: text/plain, Size: 256 bytes --]


-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: Customizable tool bars

[Katsumi Yamaoka]

>> BTW, the following two lines appear in the terminal emulator
>> whenever I start XEmacs in the terminal even if I use the
>> -vanilla option.

>> Loading gmm-utils...
>> Loading gmm-utils...done

>>>>> In <microsoft-free.87zmljg431.fsf@youngs.au.com> Steve Youngs wrote:

> It's from over-aggressive autoloading.  And the reason you still see
> the problem with -vanilla is because -vanilla still loads the
> auto-autoloads.el files.  To _not_ load those you need -no-autoloads.

> Here's a patch to fix the spurious output to stdout...

> -;;;###autoload
>  (define-widget 'gmm-tool-bar-item (if (gmm-widget-p 'lazy) 'lazy 'gmm-lazy)
> -;;;###autoload
>  (define-widget 'gmm-tool-bar-zap-list (if (gmm-widget-p 'lazy) 'lazy 'gmm-lazy)

Thanks.  It does the trick.

Re: Customizable tool bars

[Steve Youngs]

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

* Katsumi Yamaoka <yamaoka@jpl.org> writes:

  >>>>>> In <microsoft-free.87zmljg431.fsf@youngs.au.com> Steve Youngs wrote:

  >> Here's a patch to fix the spurious output to stdout...

  > Thanks.  It does the trick.

I just tried to commit it, but CVS is timing out on me.  Can you
commit it for me, thanks.

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: Customizable tool bars

[Katsumi Yamaoka]

>>>>> In <microsoft-free.87fynb62a0.fsf@youngs.au.com> Steve Youngs wrote:

> I just tried to commit it, but CVS is timing out on me.  Can you
> commit it for me, thanks.

Done.

However, all the gmm- functions still have the autoload cookies.
If they are intended to be used in the future by modules that
don't do (require 'gmm-utils), the ones for those widgets might
be also necessary after all.

Re: Customizable tool bars

[Reiner Steib]

On Thu, Jan 26 2006, Katsumi Yamaoka wrote:

> However, all the gmm- functions still have the autoload cookies.
> If they are intended to be used in the future by modules that
> don't do (require 'gmm-utils), the ones for those widgets might
> be also necessary after all.

That's why I added them in the first place.

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

Re: Customizable tool bars

[Katsumi Yamaoka]

>>>>> In <v9u0brs5x1.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

> On Thu, Jan 26 2006, Katsumi Yamaoka wrote:

>> However, all the gmm- functions still have the autoload cookies.
>> If they are intended to be used in the future by modules that
>> don't do (require 'gmm-utils), the ones for those widgets might
>> be also necessary after all.

> That's why I added them in the first place.

Now I doubt there might be XEmacs' bug causing it.

Re: Customizable tool bars

[Reiner Steib]

On Thu, Jan 26 2006, Katsumi Yamaoka wrote:

> Currently, it makes XEmacs be unable to start No Gnus.  For the
> workaround, I added the following form to the ~/.gnus.el file.
>
> (when (featurep 'xemacs)
>   (eval-after-load "gnus-group"
>     '(defalias 'gnus-group-make-tool-bar 'ignore))
>   (eval-after-load "gnus-sum"
>     '(defalias 'gnus-summary-make-tool-bar 'ignore)))

Did you see why this happens?  Is it because of the `:set
'gnus-summary-tool-bar-update' in the defcustoms?  Could you add
appropriate defaliases in `gnus-xmas.el' (or gnus-group.el and
gnus-sum.el)?

> BTW, the following two lines appear in the terminal emulator
> whenever I start XEmacs in the terminal even if I use the
> -vanilla option.
>
> Loading gmm-utils...
> Loading gmm-utils...done
>
> Does anyone know why?  They are entered in the beginning of the
> " *Message-Log*" buffer as well.

I seem to recall similar reports (unrelated to Gnus) on XEmacs lists.
Isn't this in fact an XEmacs bug?

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

Re: Customizable tool bars

[Katsumi Yamaoka]

>>>>> In <v9k6cns5ny.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

> On Thu, Jan 26 2006, Katsumi Yamaoka wrote:

>> Currently, it makes XEmacs be unable to start No Gnus.  For the
>> workaround, I added the following form to the ~/.gnus.el file.
>>
>> (when (featurep 'xemacs)
>>   (eval-after-load "gnus-group"
>>     '(defalias 'gnus-group-make-tool-bar 'ignore))
>>   (eval-after-load "gnus-sum"
>>     '(defalias 'gnus-summary-make-tool-bar 'ignore)))

> Did you see why this happens?

No, I didn't.

> Is it because of the `:set 'gnus-summary-tool-bar-update' in
> the defcustoms?

No, it may not be so.  First I got:

Debugger entered--Lisp error: (void-variable tool-bar-mode)
  default-value(tool-bar-mode)
  gnus-group-make-tool-bar()
  gnus-group-mode()
  gnus-group-setup-buffer()
  gnus-group-list-groups(1)
  byte-code...
  gnus-1(1 nil nil)
  gnus(1)

Then I eval'd (setq tool-bar-mode t) and XEmacs reported:

Debugger entered--Lisp error: (void-function tool-bar-add-item-from-menu)
  tool-bar-add-item-from-menu(gnus-group-get-new-news "get-news" #<keymap...
[...]
  gmm-tool-bar-from-list(gnus-group-tool-bar-retro t gnus-group-mode-map)
  gnus-group-make-tool-bar()
[...]

> Could you add appropriate defaliases in `gnus-xmas.el' (or
> gnus-group.el and gnus-sum.el)?

Yes, I will do it next week, if it will do.

;; I'm getting a cold and probably I should go to bed.

Re: Customizable tool bars

[Reiner Steib]

On Thu, Jan 26 2006, Katsumi Yamaoka wrote:

> Debugger entered--Lisp error: (void-variable tool-bar-mode)
>   default-value(tool-bar-mode)
>   gnus-group-make-tool-bar()
>   gnus-group-mode()
[...]
> Then I eval'd (setq tool-bar-mode t) and XEmacs reported:
>
> Debugger entered--Lisp error: (void-function tool-bar-add-item-from-menu)
>   tool-bar-add-item-from-menu(gnus-group-get-new-news "get-news" #<keymap...
> [...]
>   gmm-tool-bar-from-list(gnus-group-tool-bar-retro t gnus-group-mode-map)
>   gnus-group-make-tool-bar()

Did the following changes fix it?

	* gnus-sum.el (gnus-summary-make-tool-bar): Add checks for XEmacs
	and tool-bar-mode.

	* gnus-group.el (gnus-group-make-tool-bar): Add checks for XEmacs
	and tool-bar-mode.

	* message.el (message-tool-bar-update): Simplify.
	(message-make-tool-bar): Add checks for XEmacs and tool-bar-mode.

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

Re: Customizable tool bars

[Katsumi Yamaoka]

>>>>> In <v9lkx3ghem.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

> On Thu, Jan 26 2006, Katsumi Yamaoka wrote:

>> Debugger entered--Lisp error: (void-variable tool-bar-mode)
>> Debugger entered--Lisp error: (void-function tool-bar-add-item-from-menu)

> Did the following changes fix it?

> 	* gnus-sum.el (gnus-summary-make-tool-bar): Add checks for XEmacs
> 	and tool-bar-mode.

> 	* gnus-group.el (gnus-group-make-tool-bar): Add checks for XEmacs
> 	and tool-bar-mode.

> 	* message.el (message-tool-bar-update): Simplify.
> 	(message-make-tool-bar): Add checks for XEmacs and tool-bar-mode.

Yes, now I can start Gnus in XEmacs with no problem.  Thank you.
Additionally, I've made gnus-group.el and gnus-sum.el bind
tool-bar-mode instead of tool-bar-map when compiling in order to
avoid the compiler warning:

  ** reference to free variable tool-bar-mode

Similarly, I've made message.el bind only tool-bar-mode.


;; I survived the flu. ;-)

Re: Customizable tool bars

[Reiner Steib]

On Wed, Jan 25 2006, Reiner Steib wrote:

> On Fri, Jan 20 2006, Reiner Steib wrote:
>> I've committed a customizable tool bar interface for message mode
>> (Emacs only, not XEmacs).  There should not be any user-visible
>> difference yet, because I haven't committed the new icons yet[1].

The new icons have been committed.  Thanks to Bill Wohler for the
discussion on sharing icons with MH-E and to Adam Sjøgren for
preparing some icons.

> If you'd like to try the new icons, [...] customize the variables
> message-tool-bar, gnus-group-tool-bar and gnus-summary-tool-bar to
> GNOME style (M-x customize-apropos RET -tool-bar$ RET) [...]

Or use the following code:

--8<---------------cut here---------------start------------->8---
(dolist (i '(message gnus-group gnus-summary))
  (let ((var (intern (format "%s-tool-bar" i)))
	(gno (intern (format "%s-tool-bar-gnome" i)))
	(fun (intern (format "%s-tool-bar-update" i))))
    (set var gno)
    (when (fboundp fun)
      (funcall fun))))
--8<---------------cut here---------------end--------------->8---

As always: Feedback welcome.

I think I will enable the new tool bars by default within the next
days.  Maybe only on Emacs 22 and/or depending on the color capacities
of the display.  In Emacs 21, you currently get a mixture of old
Emacs-21-icons and new GNOME-style icons.

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

Re: Customizable tool bars

[Katsumi Yamaoka]

>>>>> In <v9r75wnygh.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

> The new icons have been committed.  Thanks to Bill Wohler for the
> discussion on sharing icons with MH-E and to Adam Sjøgren for
> preparing some icons.

Thank you for installing good features.  The Gnome icons work
fine so far (they look to me somewhat gaudy, though I will get
used to them sooner or later ;-).

However, the default retro icons didn't appear in the toolbars.
I've modified icon files specified in `gnus-group-tool-bar-retro'
and `gnus-summary-tool-bar-retro' so that they might be under
the "gnus/" subdirectory.  Is it a proper change?  I didn't
touch `message-tool-bar-retro' since there're no retro icons for
the message-mode.

In addition, there was another problem.  I don't customize
`gmm-image-load-path' (because its docstring doesn't begin with
"*") but add the proper image path to `image-load-path' as
follows:

(push "/usr/local/share/emacs/etc/images/" image-load-path)

However, `gmm-image-load-path' was set to
"/usr/local/share/emacs/etc/images/gnus/".  I've fixed the
`gmm-image-load-path' function so as to remove subdirectories
which the second argument `image' might have.  The reason that I
need to modify `image-load-path' is that I use the configure
options

 --with-lispdir=/usr/local/share/emacs/EMACS-VERSION/site-lisp/gnus
 --with-etcdir=/usr/local/share/emacs/etc

when installing Gnus.  So, the icon files are installed under
the "/usr/local/share/emacs/etc/images/" directory, not the
"/usr/local/share/emacs/EMACS-VERSION/site-lisp/gnus/../../etc/images"
directory.  I also added "/usr/local/share/emacs/etc/images/" to
`load-path' for Emacs 21.

> I think I will enable the new tool bars by default within the next
> days.

I think making the new feature the default is a good idea.

> Maybe only on Emacs 22 and/or depending on the color capacities
> of the display.  In Emacs 21, you currently get a mixture of old
> Emacs-21-icons and new GNOME-style icons.

image-load-path/load-path function (was: Customizable tool bars)

[Reiner Steib]

[ Adding mh-e-devel.  The function is intended to be shared by MH-E
  and Gnus and such problems may also arise for MH-E users.  Maybe
  they already have an idea concerning this problem.  For previous
  discussion about this function, see
  http://thread.gmane.org/v964n9ybgs.fsf%40marauder.physik.uni-ulm.de ]

On Wed, Feb 22 2006, Katsumi Yamaoka wrote:

> In addition, there was another problem.  I don't customize
> `gmm-image-load-path' (because its docstring doesn't begin with
> "*") but add the proper image path to `image-load-path' as
> follows:
>
> (push "/usr/local/share/emacs/etc/images/" image-load-path)
>
> However, `gmm-image-load-path' was set to
> "/usr/local/share/emacs/etc/images/gnus/".  I've fixed the
> `gmm-image-load-path' function so as to remove subdirectories
> which the second argument `image' might have.  The reason that I
> need to modify `image-load-path' is that I use the configure
> options
>
>  --with-lispdir=/usr/local/share/emacs/EMACS-VERSION/site-lisp/gnus
>  --with-etcdir=/usr/local/share/emacs/etc
>
> when installing Gnus.  So, the icon files are installed under
> the "/usr/local/share/emacs/etc/images/" directory, not the
> "/usr/local/share/emacs/EMACS-VERSION/site-lisp/gnus/../../etc/images"
> directory.  I also added "/usr/local/share/emacs/etc/images/" to
> `load-path' for Emacs 21.

Below is the current version including this fix.  Comments?

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

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

(defun gmm-image-load-path (library image &optional 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   (error "No image specified."))
  (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))))
	((let ((img image)
	       (dir (or
		     ;; Images in image-load-path.
		     (gmm-image-search-load-path image)
		     ;; Images in load-path.
		     (locate-library image)))
	       parent)
	   (and dir
		(setq dir (file-name-directory dir))
		(progn
		  ;; Remove subdirectories.
		  (while (setq parent (file-name-directory img))
		    (setq img (directory-file-name parent)
			  dir (expand-file-name "../" dir)))
		  (setq gmm-image-load-path dir))))))
  ;;
  (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)
		(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)))))
--8<---------------cut here---------------end--------------->8---

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


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

Re: image-load-path/load-path function

[Reiner Steib]

On Wed, Feb 22 2006, Reiner Steib wrote:

> Below is the current version including this fix.

When running Gnus directly from the CVS checkout or from the extracted
tarball (only "make", no "make install" = Lars' recommended procedure)
the images are in "../etc/images", not in "../../etc/images".

I've installed the following change to address this situation:

	* gmm-utils.el (gmm-image-load-path): Also search in
	"../etc/images".  Don't set gmm-image-load-path if we don't find
	the image.

Please use the following command to get an uptodate version of
`gmm-utils.el' if you don't have a full checkout of the Gnus CVS
trunk:

$ cvs -d :pserver:gnus@cvs.gnus.org:/usr/local/cvsroot login
CVS password: gnus
$ cvs -d :pserver:gnus@cvs.gnus.org:/usr/local/cvsroot checkout gnus/lisp/gmm-utils.el

(cf. http://www.gnus.org/distribution.html)

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


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

Re: image-load-path/load-path function

[Katsumi Yamaoka]

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

>>>>> In <v94q2r5tt9.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

> When running Gnus directly from the CVS checkout or from the extracted
> tarball (only "make", no "make install" = Lars' recommended procedure)
> the images are in "../etc/images", not in "../../etc/images".

> I've installed the following change to address this situation:

> 	* gmm-utils.el (gmm-image-load-path): Also search in
> 	"../etc/images".  Don't set gmm-image-load-path if we don't find
> 	the image.

By the way, how about making Gnus be able to start even if icon
files have not been installed?  I'm not sure whether it is
applicable to MH-E, though.

2006-02-23  Katsumi Yamaoka  <yamaoka@jpl.org>

	* gmm-utils.el (gmm-image-load-path): Don't stop even if no icon
	files have installed; don't modify image-load-path and load-path.


[-- Attachment #2: Type: application/emacs-lisp, Size: 2725 bytes --]

Re: image-load-path/load-path function

[Reiner Steib]

On Thu, Feb 23 2006, Katsumi Yamaoka wrote:

> By the way, how about making Gnus be able to start even if icon
> files have not been installed?  I'm not sure whether it is
> applicable to MH-E, though.

In Gnus, `gmm-image-load-path' is used only if `tool-bar-mode' is
bound and non-nil.  But maybe a warning is sufficient.  I recall some
discussion about the rational for this on the MH-E list, but I can't
find right now.  Bill, Peter?

> 2006-02-23  Katsumi Yamaoka  <yamaoka@jpl.org>
>
> 	* gmm-utils.el (gmm-image-load-path): Don't stop even if no icon
> 	files have installed; don't modify image-load-path and load-path.

In any case, please install the "don't modify" part.

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


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

Re: image-load-path/load-path function

[Katsumi Yamaoka]

>>>>> In <v9y802s38x.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Thu, Feb 23 2006, Katsumi Yamaoka wrote:

>> By the way, how about making Gnus be able to start even if icon
>> files have not been installed?  I'm not sure whether it is
>> applicable to MH-E, though.

> In Gnus, `gmm-image-load-path' is used only if `tool-bar-mode' is
> bound and non-nil.  But maybe a warning is sufficient.  I recall some
> discussion about the rational for this on the MH-E list, but I can't
> find right now.  Bill, Peter?

Though it might be my needless anxiety.  If Gnus could start
without icons formerly (I'll verify it tomorrow), it might
confuse some users.

>> 2006-02-23  Katsumi Yamaoka  <yamaoka@jpl.org>
>>
>> 	* gmm-utils.el (gmm-image-load-path): Don't stop even if no icon
>> 	files have installed; don't modify image-load-path and load-path.

> In any case, please install the "don't modify" part.

Committed.

Re: image-load-path/load-path function

[Reiner Steib]

On Thu, Feb 23 2006, Katsumi Yamaoka wrote:

>>>>>> In <v9y802s38x.fsf@marauder.physik.uni-ulm.de>
>>>>>>	Reiner Steib <reinersteib+gmane@imap.cc> wrote:
>
>> On Thu, Feb 23 2006, Katsumi Yamaoka wrote:
>
>>> By the way, how about making Gnus be able to start even if icon
>>> files have not been installed?  I'm not sure whether it is
>>> applicable to MH-E, though.
>
>> In Gnus, `gmm-image-load-path' is used only if `tool-bar-mode' is
>> bound and non-nil.  But maybe a warning is sufficient.  I recall some
>> discussion about the rational for this on the MH-E list, but I can't
>> find right now.  Bill, Peter?
>
> Though it might be my needless anxiety.  If Gnus could start
> without icons formerly (I'll verify it tomorrow), it might
> confuse some users.

Gnus could start without any icons before.  The corresponding tool bar
icons were missing (try adding a bogus filename e.g. to
message-tool-bar-gnome).  So I think it there should not be an error.

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


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

Re: image-load-path/load-path function

[Katsumi Yamaoka]

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

>>>>> In <v9accidrz6.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

> On Thu, Feb 23 2006, Katsumi Yamaoka wrote:

>> Though it might be my needless anxiety.  If Gnus could start
>> without icons formerly (I'll verify it tomorrow), it might
>> confuse some users.

> Gnus could start without any icons before.  The corresponding tool bar
> icons were missing (try adding a bogus filename e.g. to
> message-tool-bar-gnome).

I also confirmed it.

> So I think it there should not be an error.

I think so.  Though it is not good that `tool-bar-mode' is not
turned off despite no images, it is not as serious as we should
stop Gnus starting.  Users need to read new mails at once anyway.

How about this way? --- add the optional NOERROR argument to
`gmm-image-load-path'; make Gnus always specify that argument.
Here's a modified part of gmm-utils.el and a diff to the other
files (they include some irrelevant and not significant changes):

2006-02-24  Katsumi Yamaoka  <yamaoka@jpl.org>

	* gmm-utils.el (gmm-image-load-path): Add optional NOERROR
	argument; don't cause error if it is specified; set the variable
	gmm-image-load-path to not-found in order not to issue warning two
	or more times if directory containing images is not found; make
	sure gmm-image-load-path doesn't appear in result twice.

	* gnus-group.el (gnus-group-make-tool-bar): Specify optional
	NOERROR argument to gmm-image-load-path.

	* gnus-sum.el (gnus-summary-make-tool-bar): Ditto.

	* message.el (message-make-tool-bar): Ditto.


[-- Attachment #2: Type: application/emacs-lisp, Size: 3769 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Type: text/x-patch, Size: 1686 bytes --]

--- gnus-group.el~	2006-02-23 21:46:07 +0000
+++ gnus-group.el	2006-02-24 08:00:37 +0000
@@ -1117,10 +1117,10 @@
 	     (or (not gnus-group-tool-bar-map) force))
     (let* ((load-path
 	    (gmm-image-load-path "gnus" "gnus/toggle-subscription.xpm"
-				 'load-path))
+				 'load-path t))
 	   (image-load-path
 	    (gmm-image-load-path "gnus" "gnus/toggle-subscription.xpm"
-				 'image-load-path))
+				 'image-load-path t))
 	   (map (gmm-tool-bar-from-list gnus-group-tool-bar
 					gnus-group-tool-bar-zap-list
 					'gnus-group-mode-map)))
--- gnus-sum.el~	2006-02-23 21:46:07 +0000
+++ gnus-sum.el	2006-02-24 08:00:37 +0000
@@ -2770,9 +2770,9 @@
 	     tool-bar-mode
 	     (or (not gnus-summary-tool-bar-map) force))
     (let* ((load-path
-	    (gmm-image-load-path "gnus" "mail/save.xpm" 'load-path))
+	    (gmm-image-load-path "gnus" "mail/save.xpm" 'load-path t))
 	   (image-load-path
-	    (gmm-image-load-path "gnus" "mail/save.xpm" 'image-load-path))
+	    (gmm-image-load-path "gnus" "mail/save.xpm" 'image-load-path t))
 	   (map (gmm-tool-bar-from-list gnus-summary-tool-bar
 					gnus-summary-tool-bar-zap-list
 					'gnus-summary-mode-map)))
--- message.el~	2006-02-24 04:59:45 +0000
+++ message.el	2006-02-24 08:00:37 +0000
@@ -6803,10 +6803,10 @@
     (setq message-tool-bar-map
 	  (let ((load-path
 		 (gmm-image-load-path "message" "mail/save-draft.xpm"
-				      'load-path))
+				      'load-path t))
 		(image-load-path
 		 (gmm-image-load-path "message" "mail/save-draft.xpm"
-				      'image-load-path)))
+				      'image-load-path t)))
 	    (gmm-tool-bar-from-list message-tool-bar
 				    message-tool-bar-zap-list
 				    'message-mode-map))))

Re: image-load-path/load-path function

[Katsumi Yamaoka]

>>>>> In <b4mvev5qj35.fsf@jpl.org> Katsumi Yamaoka wrote:

> Here's a modified part of gmm-utils.el...

Sorry.  The form under the line

"  ;; Return augmented `image-load-path' or `load-path'."

should be replaced with the following to make Emacs 21 work.

--8<---------------cut here---------------start------------->8---
  ;; Return augmented `image-load-path' or `load-path'.
  (cond ((and path (symbolp path) (boundp path))
	 (if (eq gmm-image-load-path 'not-found)
	     (copy-sequence (symbol-value path))
	   (nconc (list gmm-image-load-path)
		  (delete gmm-image-load-path
			  (copy-sequence (symbol-value path))))))
	((eq gmm-image-load-path 'not-found)
	 (copy-sequence load-path))
	(t
	 (nconc (list gmm-image-load-path)
		(delete gmm-image-load-path
			(copy-sequence load-path))))))
--8<---------------cut here---------------end--------------->8---

Re: image-load-path/load-path function

[Bill Wohler]

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

> On Thu, Feb 23 2006, Katsumi Yamaoka wrote:
> 
> > By the way, how about making Gnus be able to start even if icon
> > files have not been installed?  I'm not sure whether it is
> > applicable to MH-E, though.
> 
> In Gnus, `gmm-image-load-path' is used only if `tool-bar-mode' is
> bound and non-nil.  But maybe a warning is sufficient.  I recall some
> discussion about the rational for this on the MH-E list, but I can't
> find right now.  Bill, Peter?

We used to create the tool bar icons at load time, but now we create
them in our various modes. We create them unconditionally at the moment,
but that can be changed easily.

I think it is reasonable to proceed if the icons can't be found if
tool-bar-mode is nil (since the user might not have any icons installed
to save space and run with the tool bar turned off).

My first choice would be to throw an error if the icons can't be found
and tool-bar-mode is non-nil (or if initially it is nil and later the
user turns on the tool bar). My rationale is based upon a philosophy of
throwing errors early. The user will get a specific message about the
problem rather than later wondering why the tool bar looks strange (and
missing a message in the *Messages* buffer which has since scrolled off
the top of the buffer).

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

Re: image-load-path/load-path function

[Bill Wohler]

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

> Below is the current version including this fix.  Comments?

Reiner,

Unfortunately, I haven't been able to stimulate any discussion on the
issue about modifying or not modifying image-load-path on emacs-devel.
So I haven't heard any arguments against modifying the path, let alone
arguments that are more compelling than my own. But I think that in
order to expedite getting image-load-path (the function) into image.el
so that we can use *-defun-compat to simply alias (or define) it in our
own code, I think I'll update the MH-E code to use scoped variables in
the same way that you folks do, barring dissent from the MH-E masses.

I'll work on porting your posted version back to MH-E so that they will
be as close together as possible. If you've changed it since your post
last Wednesday, please let me know (maybe sending me the URL to the file
in your repository might be a good idea, ours is
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-utils.el?root=emacs&view=markup).

(So there will be a slight delay in the 7.93 release.)

Once our two versions are the same (modulo the prefix), I'll add a
function called "image-load-path" to image.el, although maybe we should
talk about the name first.

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

I've already renamed this to mh-image-directory per your suggestion.

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

Re: image-load-path/load-path function

[Bill Wohler]

Bill Wohler <wohler@newt.com> wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> >
> > (defvar gmm-image-load-path nil
> >   "Directory where images are found.
> > See the function `gmm-image-load-path'.")
> 
> I've already renamed this to mh-image-directory per your suggestion.

While converting our code to use your version, it occurred to me that it
would be more general to use an *-image-load-path variable since the
user might have their own images in more than one place.

And then if we were to move this function and the variable to image.el,
we'd rename the variable to image-load-path. Which already exists. Which
made me think that perhaps this variable is redundant.

Since it was Peter and Debian which suggested the use of this variable
in the first place, and now that the function checks both load-path and
image-load-path for the library's images, I'd like to ask Peter if it
would be OK to change the line in emacsen-startup:

  (setq mh-image-directory "/usr/share/emacs/site-lisp/etc/images/mh-e")

to

  (if (boundp 'image-load-path)
      (add-to-list 'image-load-path
                   "/usr/share/emacs/site-lisp/etc/images/mh-e")
    (add-to-list 'load-path "/usr/share/emacs/site-lisp/etc/images/mh-e"))

Is this called late enough so that
/usr/share/emacs/site-lisp/etc/images/mh-e would be placed in front of
the standard images directory?

If this seems OK to everyone, I'll make *-image-directory a local
variable within *-image-load-path.

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


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

Re: image-load-path/load-path function

[Peter S Galbraith]

Bill Wohler <wohler@newt.com> wrote:

> Since it was Peter and Debian which suggested the use of this variable
> in the first place, and now that the function checks both load-path and
> image-load-path for the library's images, I'd like to ask Peter if it
> would be OK to change the line in emacsen-startup:
> 
>   (setq mh-image-directory "/usr/share/emacs/site-lisp/etc/images/mh-e")
> 
> to
> 
>   (if (boundp 'image-load-path)
>       (add-to-list 'image-load-path
>                    "/usr/share/emacs/site-lisp/etc/images/mh-e")
>     (add-to-list 'load-path "/usr/share/emacs/site-lisp/etc/images/mh-e"))
> 
> Is this called late enough so that
> /usr/share/emacs/site-lisp/etc/images/mh-e would be placed in front of
> the standard images directory?

Yes it would be.  I can do that for the next release.

:-)

-- 
Peter


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

Re: image-load-path/load-path function

[Reiner Steib]

[ In my previous mail, I hit C-c C-c too early. ;-) ]

On Thu, Mar 02 2006, Peter S Galbraith wrote:

> Bill Wohler <wohler@newt.com> wrote:
>
>> Since it was Peter and Debian which suggested the use of this variable
>> in the first place, and now that the function checks both load-path and
>> image-load-path for the library's images, I'd like to ask Peter if it
>> would be OK to change the line in emacsen-startup:
[...]
>> Is this called late enough so that
>> /usr/share/emacs/site-lisp/etc/images/mh-e would be placed in front of
>> the standard images directory?
>
> Yes it would be.  I can do that for the next release.

[...]
>> If this seems OK to everyone, I'll make *-image-directory a local
>> variable within *-image-load-path.

A _minor_ disadvantage is that the library&image search will be
performed on each call of the function `*-image-load-path'.

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

Re: image-load-path/load-path function

[Bill Wohler]

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

> >> If this seems OK to everyone, I'll make *-image-directory a local
> >> variable within *-image-load-path.
> 
> A _minor_ disadvantage is that the library&image search will be
> performed on each call of the function `*-image-load-path'.

Ah, now I see why you removed *-image-load-path-called: you were using
*-image-directory for that purpose.

If the global were preserved in image.el, I think it would have to be an
alist mapping LIBRARY to the related image directory. Maybe this would
be more complication than needed since it would only save a call to
locate-library and file-exists-p. If calls to *-image-load-path are not
in a tight loop--indeed, in MH-E it is only called twice--I'm thinking
that we might not worry unless it becomes a problem. Would that be the
consensus?

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

Re: image-load-path/load-path function

[Reiner Steib]

On Thu, Mar 02 2006, Bill Wohler wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
[...]
>> A _minor_ disadvantage is that the library&image search will be
>> performed on each call of the function `*-image-load-path'.
>
> Ah, now I see why you removed *-image-load-path-called: you were using
> *-image-directory for that purpose.

... and I already had forgotten that you had an extra variable for
that.  ;-)

> If the global were preserved in image.el, I think it would have to be an
> alist mapping LIBRARY to the related image directory. Maybe this would
> be more complication than needed since it would only save a call to
> locate-library and file-exists-p. If calls to *-image-load-path are not
> in a tight loop--indeed, in MH-E it is only called twice--I'm thinking
> that we might not worry unless it becomes a problem. Would that be the
> consensus?

I agree.

FWIW: In Gnus it's called more often (twice for each mode
initialization; modes: group, summary and message).

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


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

Re: image-load-path/load-path function

[Bill Wohler]

Rainer,

I copied your *-image-load-path function, changed gmm to mh, made a
couple of changes (listed below), and updated our software to use scoped
copies of image-load-path/load-path.

- Delete mh-image-directory variable per previous email.

- Remove periods from (error) strings per Emacs conventions. See Info
  node `(elisp)Programming Tips'.

- Remove quotes around %s. There isn't an explicit Emacs convention
  about this, but it's used in less than 10% of the cases so I made it
  an MH-E convention.

- Add comment before a bit that took me a minute to grok.

I think we're ready to move it to image.el. Let me know if you think I
should proceed.

I think the name image-load-path would be fine: If you ask for the
variable image-load-path, you get the image load path, if you ask for
the function image-load-path, you get the image load path. Seems
consistent. What do you think?


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

Images for LIBRARY are searched for in \"../../etc/images\" and
\"../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   (error "No image specified"))
  (let ((mh-image-directory))
    (cond
     ;; Try relative setting.
     ((let (mh-library-name d1ei d2ei)
        ;; First, find library in the load-path.
        (setq mh-library-name (locate-library library))
        (if (not mh-library-name)
            (error "Cannot find library %s in load-path" library))
        ;; And then set mh-image-directory relative to that.
        (setq
         ;; Go down 2 levels.
         d2ei (expand-file-name
               (concat (file-name-directory mh-library-name)
                       "../../etc/images"))
         ;; Go down 1 level.
         d1ei (expand-file-name
               (concat (file-name-directory mh-library-name)
                       "../etc/images")))
        (setq mh-image-directory
              ;; Set it to nil if image is not found.
              (cond ((file-exists-p (expand-file-name image d2ei)) d2ei)
                    ((file-exists-p (expand-file-name image d1ei)) d1ei)))))
     ;; Check for images in image-load-path or load-path.
     ((let ((img image)
            (dir (or
                  ;; Images in image-load-path.
                  (mh-image-search-load-path image)
                  ;; Images in load-path.
                  (locate-library image)))
            parent)
        ;; Since the image might be in a nested directory
        ;; (for example, mail/attach.pbm), adjust `mh-image-directory'
        ;; accordingly.
        (and dir
             (setq dir (file-name-directory dir))
             (progn
               (while (setq parent (file-name-directory img))
                 (setq img (directory-file-name parent)
                       dir (expand-file-name "../" dir)))
               (setq mh-image-directory dir))))))
    ;;
    (unless (file-exists-p mh-image-directory)
      (error "Directory %s in mh-image-directory does not exist"
	     mh-image-directory))
    (unless (file-exists-p (expand-file-name image mh-image-directory))
      (error "Directory %s in mh-image-directory does not contain image %s"
             mh-image-directory image))
    ;; Return augmented `image-load-path' or `load-path'.
    (cond ((and path (symbolp path))
           (nconc (list mh-image-directory)
                  (delete mh-image-directory
                          (if (boundp path)
                              (copy-sequence (symbol-value path))
                            nil))))
          (t
           (nconc (list mh-image-directory)
                  (delete mh-image-directory
                          (copy-sequence load-path)))))))
-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


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

Re: image-load-path/load-path function

[Bill Wohler]

Bill Wohler <wohler@newt.com> wrote:

> Rainer,

s/Rainer/Reiner/

Whoops, sorry about 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 xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: image-load-path/load-path function

[Reiner Steib]

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

On Fri, Mar 03 2006, Bill Wohler wrote:

> I think we're ready to move it to image.el. Let me know if you think I
> should proceed.
>
> I think the name image-load-path would be fine: If you ask for the
> variable image-load-path, you get the image load path, if you ask for
> the function image-load-path, you get the image load path. Seems
> consistent. What do you think?

Maybe `image-relative-load-path' or `image-load-path-relative' to make
it more clear?

> (defun mh-image-load-path (library image &optional path)
>   "Return a suitable search path for images of LIBRARY.
>
> Images for LIBRARY are searched for in \"../../etc/images\" and
> \"../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'."

Adding a calling example to doc string won't hurt.  Maybe emphasize
that IMAGE must include the extension, e.g. .xpm (maybe not necessary
when we give an example).

>   (let ((mh-image-directory))
[...]
>      ((let (mh-library-name d1ei d2ei)

The local variables mh-image-directory and mh-library-name should have
a non-prefixed name e.g. image-dir and library-name.  This would also
make synching more easy.  See the attached patch against
emacs/lisp/mh-e/mh-utils.el.

>     (unless (file-exists-p mh-image-directory)
>       (error "Directory %s in mh-image-directory does not exist"
> 	     mh-image-directory))
>     (unless (file-exists-p (expand-file-name image mh-image-directory))
>       (error "Directory %s in mh-image-directory does not contain image %s"
>              mh-image-directory image))

As mh-image-directory cannot be not a user-specified directory
anymore, I doubt that these errors are very useful.  But if you'd like
to keep these two `error' calls, we should add an optional no-error
argument as suggested by Katsumi Yamaoka.  We would set this to t in
Gnus and the function would use `message' or `error' depending on its
value.

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 3503 bytes --]

--- mh-utils.el	03 Mar 2006 13:59:57 +0100	1.57
+++ mh-utils.el	03 Mar 2006 17:34:28 +0100	
@@ -94,25 +94,25 @@
 `load-path'."
   (unless library (error "No library specified"))
   (unless image   (error "No image specified"))
-  (let ((mh-image-directory))
+  (let ((image-dir))
     (cond
      ;; Try relative setting.
-     ((let (mh-library-name d1ei d2ei)
+     ((let (library-name d1ei d2ei)
         ;; First, find library in the load-path.
-        (setq mh-library-name (locate-library library))
-        (if (not mh-library-name)
+        (setq library-name (locate-library library))
+        (if (not library-name)
             (error "Cannot find library %s in load-path" library))
-        ;; And then set mh-image-directory relative to that.
+        ;; And then set image-dir relative to that.
         (setq
          ;; Go down 2 levels.
          d2ei (expand-file-name
-               (concat (file-name-directory mh-library-name)
+               (concat (file-name-directory library-name)
                        "../../etc/images"))
          ;; Go down 1 level.
          d1ei (expand-file-name
-               (concat (file-name-directory mh-library-name)
+               (concat (file-name-directory library-name)
                        "../etc/images")))
-        (setq mh-image-directory
+        (setq image-dir
               ;; Set it to nil if image is not found.
               (cond ((file-exists-p (expand-file-name image d2ei)) d2ei)
                     ((file-exists-p (expand-file-name image d1ei)) d1ei)))))
@@ -125,7 +125,7 @@
                   (locate-library image)))
             parent)
         ;; Since the image might be in a nested directory
-        ;; (for example, mail/attach.pbm), adjust `mh-image-directory'
+        ;; (for example, mail/attach.pbm), adjust `image-dir'
         ;; accordingly.
         (and dir
              (setq dir (file-name-directory dir))
@@ -133,24 +133,24 @@
                (while (setq parent (file-name-directory img))
                  (setq img (directory-file-name parent)
                        dir (expand-file-name "../" dir)))
-               (setq mh-image-directory dir))))))
+               (setq image-dir dir))))))
     ;;
-    (unless (file-exists-p mh-image-directory)
-      (error "Directory %s in mh-image-directory does not exist"
-	     mh-image-directory))
-    (unless (file-exists-p (expand-file-name image mh-image-directory))
-      (error "Directory %s in mh-image-directory does not contain image %s"
-             mh-image-directory image))
+    (unless (file-exists-p image-dir)
+      (error "Directory %s in image-dir does not exist"
+	     image-dir))
+    (unless (file-exists-p (expand-file-name image image-dir))
+      (error "Directory %s in image-dir does not contain image %s"
+             image-dir image))
     ;; Return augmented `image-load-path' or `load-path'.
     (cond ((and path (symbolp path))
-           (nconc (list mh-image-directory)
-                  (delete mh-image-directory
+           (nconc (list image-dir)
+                  (delete image-dir
                           (if (boundp path)
                               (copy-sequence (symbol-value path))
                             nil))))
           (t
-           (nconc (list mh-image-directory)
-                  (delete mh-image-directory
+           (nconc (list image-dir)
+                  (delete image-dir
                           (copy-sequence load-path)))))))
 
 ;;;###mh-autoload

Re: image-load-path/load-path function

[Bill Wohler]

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

> On Fri, Mar 03 2006, Bill Wohler wrote:
> 
> > I think we're ready to move it to image.el. Let me know if you think I
> > should proceed.
> >
> > I think the name image-load-path would be fine: If you ask for the
> > variable image-load-path, you get the image load path, if you ask for
> > the function image-load-path, you get the image load path. Seems
> > consistent. What do you think?
> 
> Maybe `image-relative-load-path' or `image-load-path-relative' to make
> it more clear?

Hmmm, I'm not entirely enamored with these. If not image-load-path, then
perhaps something like image-load-path-for-library since library is the
first argument.

> > (defun mh-image-load-path (library image &optional path)
> >   "Return a suitable search path for images of LIBRARY.
> >
> > Images for LIBRARY are searched for in \"../../etc/images\" and
> > \"../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'."
> 
> Adding a calling example to doc string won't hurt.  Maybe emphasize
> that IMAGE must include the extension, e.g. .xpm (maybe not necessary
> when we give an example).

I was thinking the very same thing.

> >   (let ((mh-image-directory))
> [...]
> >      ((let (mh-library-name d1ei d2ei)
> 
> The local variables mh-image-directory and mh-library-name should have
> a non-prefixed name e.g. image-dir and library-name.  This would also
> make synching more easy.

Agreed. That occurred to me too, and it seems that there aren't any
variables in the functions we call that we might clobber. I'd prefer the
non-abbreviated name image-directory, if you don't mind.

>                           See the attached patch against
> emacs/lisp/mh-e/mh-utils.el.

Thanks.

> >     (unless (file-exists-p mh-image-directory)
> >       (error "Directory %s in mh-image-directory does not exist"
> > 	     mh-image-directory))
> >     (unless (file-exists-p (expand-file-name image mh-image-directory))
> >       (error "Directory %s in mh-image-directory does not contain image %s"
> >              mh-image-directory image))
> 
> As mh-image-directory cannot be not a user-specified directory
> anymore, I doubt that these errors are very useful.  But if you'd like
> to keep these two `error' calls, we should add an optional no-error
> argument as suggested by Katsumi Yamaoka.  We would set this to t in
> Gnus and the function would use `message' or `error' depending on its
> value.

Good catch. Actually, I just found that there was a bug in this code
since if the given image couldn't be found, this code would throw an
error with (file-exists-p nil).

There still needs to be an error check in case the provided image wasn't
found at all in ../../etc/images, image-load-path, or load-path. This
can be a default case in the cond. I don't think a NOERROR argument
belongs here; it belongs higher up in the call-chain.

Here's a patch coming back at you (but I'm sending another note
immediately after this one).

--- mh-utils.el.orig	2006-03-03 12:07:57.000000000 -0800
+++ mh-utils.el	2006-03-03 12:39:25.000000000 -0800
@@ -82,7 +82,7 @@
   (delete-region (point) (progn (forward-line lines) (point))))
 
 ;;;###mh-autoload
-(defun mh-image-load-path (library image &optional path)
+(defun mh-image-load-path-for-library (library image &optional path)
   "Return a suitable search path for images of LIBRARY.
 
 Images for LIBRARY are searched for in \"../../etc/images\" and
@@ -91,10 +91,20 @@
 
 This function returns value of `load-path' augmented with the
 path to IMAGE.  If PATH is given, it is used instead of
-`load-path'."
+`load-path'.
+
+Here is an example that uses a common idiom to provide
+compatibility with versions of Emacs that lack the variable
+`image-load-path':
+
+  (let ((load-path
+         (image-load-path-for-library \"mh-e\" \"mh-logo.xpm\" 'load-path))
+        (image-load-path
+         (image-load-path-for-library \"mh-e\" \"mh-logo.xpm\" 'image-load-path)))
+    (mh-tool-bar-folder-buttons-init))"
   (unless library (error "No library specified"))
   (unless image   (error "No image specified"))
-  (let ((image-dir))
+  (let ((image-directory))
     (cond
      ;; Try relative setting.
      ((let (library-name d1ei d2ei)
@@ -102,17 +112,15 @@
         (setq library-name (locate-library library))
         (if (not library-name)
             (error "Cannot find library %s in load-path" library))
-        ;; And then set image-dir relative to that.
+        ;; And then set image-directory relative to that.
         (setq
          ;; Go down 2 levels.
          d2ei (expand-file-name
-               (concat (file-name-directory library-name)
-                       "../../etc/images"))
+               (concat (file-name-directory library-name) "../../etc/images"))
          ;; Go down 1 level.
          d1ei (expand-file-name
-               (concat (file-name-directory library-name)
-                       "../etc/images")))
-        (setq image-dir
+               (concat (file-name-directory library-name) "../etc/images")))
+        (setq image-directory
               ;; Set it to nil if image is not found.
               (cond ((file-exists-p (expand-file-name image d2ei)) d2ei)
                     ((file-exists-p (expand-file-name image d1ei)) d1ei)))))
@@ -124,8 +132,8 @@
                   ;; Images in load-path.
                   (locate-library image)))
             parent)
-        ;; Since the image might be in a nested directory
-        ;; (for example, mail/attach.pbm), adjust `image-dir'
+        ;; Since the image might be in a nested directory (for
+        ;; example, mail/attach.pbm), adjust `image-directory'
         ;; accordingly.
         (and dir
              (setq dir (file-name-directory dir))
@@ -133,25 +141,20 @@
                (while (setq parent (file-name-directory img))
                  (setq img (directory-file-name parent)
                        dir (expand-file-name "../" dir)))
-               (setq image-dir dir))))))
-    ;;
-    (unless (file-exists-p image-dir)
-      (error "Directory %s in image-dir does not exist"
-	     image-dir))
-    (unless (file-exists-p (expand-file-name image image-dir))
-      (error "Directory %s in image-dir does not contain image %s"
-             image-dir image))
+               (setq image-directory dir)))))
+     (t
+      (error "Could not find image %s for library %s" image library)))
+
     ;; Return augmented `image-load-path' or `load-path'.
     (cond ((and path (symbolp path))
-           (nconc (list image-dir)
-                  (delete image-dir
+           (nconc (list image-directory)
+                  (delete image-directory
                           (if (boundp path)
                               (copy-sequence (symbol-value path))
                             nil))))
           (t
-           (nconc (list image-dir)
-                  (delete image-dir
-                          (copy-sequence load-path)))))))
+           (nconc (list image-directory)
+                  (delete image-directory (copy-sequence load-path)))))))
 
 ;;;###mh-autoload
 (defun mh-make-local-vars (&rest pairs)

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


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

Re: image-load-path/load-path function

[Bill Wohler]

Here is the same thing as my last patch, but now wrapped in a
mh-defun-compat. I've added an appropriate sentence to the end of the
docstring. Other than the first line, we should be able to use this
verbatim between MH-E and Gnus, modulo any changes we may still make.

I'm definitely now heavily leaning towards the name
image-load-path-for-library. Does it work for you too? The "relative"
variants didn't work for me since you could also pull the directories
off of load-path or image-load-path.

I just ran

  (mh-image-load-path-for-library "mh-e" "mh-logo.xpm")

and was rather surprised. In an Emacs 22 environment, given the name,
you'd expect a modified image-load-path, but you get a modified
load-path. If the optional argument path isn't present, I'd suggest
returning a modified image-load-path if it exists; else a modified
load-path. What do you think?

We could then potentially change the example (#1) to the following

#2
(let ((image-load-path (image-load-path-for-library "mh-e" "mh-logo.xpm"))
      (load-path (image-load-path-for-library "mh-e" "mh-logo.xpm")))
  (mh-tool-bar-folder-buttons-init))

or even

#3
(let* ((image-load-path (image-load-path-for-library "mh-e" "mh-logo.xpm"))
       (load-path image-load-path))
  (mh-tool-bar-folder-buttons-init))

The latter would be more efficient, but would it be too opaque? I think
my preference would be #3, #1, #2. Thoughts?



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

Images for LIBRARY are searched for in \"../../etc/images\" and
\"../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'.

Here is an example that uses a common idiom to provide
compatibility with versions of Emacs that lack the variable
`image-load-path':

  (let ((load-path
         (image-load-path-for-library \"mh-e\" \"mh-logo.xpm\" 'load-path))
        (image-load-path
         (image-load-path-for-library \"mh-e\" \"mh-logo.xpm\" 'image-load-path)))
    (mh-tool-bar-folder-buttons-init))

This function is used by Emacs versions that don't have
`image-load-path-for-library'."
  (unless library (error "No library specified"))
  (unless image   (error "No image specified"))
  (let ((image-directory))
    (cond
     ;; Try relative setting.
     ((let (library-name d1ei d2ei)
        ;; First, find library in the load-path.
        (setq library-name (locate-library library))
        (if (not library-name)
            (error "Cannot find library %s in load-path" library))
        ;; And then set image-directory relative to that.
        (setq
         ;; Go down 2 levels.
         d2ei (expand-file-name
               (concat (file-name-directory library-name) "../../etc/images"))
         ;; Go down 1 level.
         d1ei (expand-file-name
               (concat (file-name-directory library-name) "../etc/images")))
        (setq image-directory
              ;; Set it to nil if image is not found.
              (cond ((file-exists-p (expand-file-name image d2ei)) d2ei)
                    ((file-exists-p (expand-file-name image d1ei)) d1ei)))))
     ;; Check for images in image-load-path or load-path.
     ((let ((img image)
            (dir (or
                  ;; Images in image-load-path.
                  (mh-image-search-load-path image)
                  ;; Images in load-path.
                  (locate-library image)))
            parent)
        ;; Since the image might be in a nested directory (for
        ;; example, mail/attach.pbm), adjust `image-directory'
        ;; accordingly.
        (and dir
             (setq dir (file-name-directory dir))
             (progn
               (while (setq parent (file-name-directory img))
                 (setq img (directory-file-name parent)
                       dir (expand-file-name "../" dir)))
               (setq image-directory dir)))))
     (t
      (error "Could not find image %s for library %s" image library)))

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

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


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

Re: image-load-path/load-path function

[Reiner Steib]

On Fri, Mar 03 2006, Bill Wohler wrote:

> Here is the same thing as my last patch, [...]

(BTW, if it's already in Emacs CVS, you don't need to include it
here.)

> I'm definitely now heavily leaning towards the name
> image-load-path-for-library. Does it work for you too? The "relative"
> variants didn't work for me since you could also pull the directories
> off of load-path or image-load-path.

Okay with me.  Although I'd slightly prefer to emphasize "relative" a
little bit.  But maybe adding it to the doc string is sufficient:

"Return a suitable search path for images relative to LIBRARY.
[...]"

> In an Emacs 22 environment, given the name, you'd expect a modified
> image-load-path, but you get a modified load-path. If the optional
> argument path isn't present, I'd suggest returning a modified
> image-load-path if it exists; else a modified load-path. What do you
> think?

What if a user shares configuration files between Emacs 21 and 22 and
sets `image-load-path' unconditionally (without a boundp test; I
sometimes don't add test such if I assume that it will be just ignored
in older Emacsen)?  The you'll get a bogus `load-path' like...

  '("/path/to/etc/images"  data-directory load-path)

(See also below...)

> We could then potentially change the example (#1) to the following
>
> #2
> (let ((image-load-path (image-load-path-for-library "mh-e" "mh-logo.xpm"))
>       (load-path (image-load-path-for-library "mh-e" "mh-logo.xpm")))
>   (mh-tool-bar-folder-buttons-init))
[...]
> #3
> (let* ((image-load-path (image-load-path-for-library "mh-e" "mh-logo.xpm"))
>        (load-path image-load-path))
>   (mh-tool-bar-folder-buttons-init))

`image-load-path' may contain symbols, `load-path' can't.  If Emacs
needs to load some library within the let statement for some reason,
it will fail.

> The latter would be more efficient, but would it be too opaque? I think
> my preference would be #3, #1, #2. Thoughts?

I think #2 and #3 both are a little problematic.

But maybe we can suggest an example which avoids calling
`image-load-path-for-library' twice:

(let* ((load-path (image-load-path-for-library "mh-e" "mh-logo.xpm"))
       (image-load-path (cons (car load-path) image-load-path)))
  ;; do something.  Test:
  image-load-path)

[...]
> Here is an example that uses a common idiom to provide
> compatibility with versions of Emacs that lack the variable
> `image-load-path':
>
>   (let ((load-path
>          (image-load-path-for-library \"mh-e\" \"mh-logo.xpm\" 'load-path))

I'd omit 'load-path as it is optional.

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


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

Re: image-load-path/load-path function

[Bill Wohler]

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

> On Fri, Mar 03 2006, Bill Wohler wrote:
> 
> > Here is the same thing as my last patch, [...]
> 
> (BTW, if it's already in Emacs CVS, you don't need to include it
> here.)

;-).

> > I'm definitely now heavily leaning towards the name
> > image-load-path-for-library. Does it work for you too? The "relative"
> > variants didn't work for me since you could also pull the directories
> > off of load-path or image-load-path.
> 
> Okay with me.  Although I'd slightly prefer to emphasize "relative" a
> little bit.  But maybe adding it to the doc string is sufficient:
> 
> "Return a suitable search path for images relative to LIBRARY.
> [...]"

OK.

> > In an Emacs 22 environment, given the name, you'd expect a modified
> > image-load-path, but you get a modified load-path. If the optional
> > argument path isn't present, I'd suggest returning a modified
> > image-load-path if it exists; else a modified load-path. What do you
> > think?
> 
> What if a user shares configuration files between Emacs 21 and 22 and
> sets `image-load-path' unconditionally (without a boundp test; I
> sometimes don't add test such if I assume that it will be just ignored
> in older Emacsen)?  The you'll get a bogus `load-path' like...

Good thinking.

> I think #2 and #3 both are a little problematic.

I'm convinced. I'll avoid them and stick with #1.

> But maybe we can suggest an example which avoids calling
> `image-load-path-for-library' twice:
> 
> (let* ((load-path (image-load-path-for-library "mh-e" "mh-logo.xpm"))
>        (image-load-path (cons (car load-path) image-load-path)))
>   ;; do something.  Test:
>   image-load-path)

That assumes we guarantee that the image-directory is always first. That
appears to be the case now. I think I'd be a little leery about
committing to this in case we find out later that we needed to preserve
the existing order in the path if the image directory was already in the
path. But if we want to commit to this, then I'll add it to the
documentation and use this example, otherwise...

> > Here is an example that uses a common idiom to provide
> > compatibility with versions of Emacs that lack the variable
> > `image-load-path':
> >
> >   (let ((load-path
> >          (image-load-path-for-library \"mh-e\" \"mh-logo.xpm\" 'load-path))
> 
> I'd omit 'load-path as it is optional.

...I'll do that. Let me know which you prefer. Maybe someone else has a
gut feel about this too. My gut tells me to avoid committing more to the
API than we have to.

Thanks for the great feedback.

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


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

Re: image-load-path/load-path function

[Bill Wohler]

Bill Wohler <wohler@newt.com> wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> 
> > On Fri, Mar 03 2006, Bill Wohler wrote:
> > 
> > But maybe we can suggest an example which avoids calling
> > `image-load-path-for-library' twice:
> > 
> > (let* ((load-path (image-load-path-for-library "mh-e" "mh-logo.xpm"))
> >        (image-load-path (cons (car load-path) image-load-path)))
> >   ;; do something.  Test:
> >   image-load-path)
> 
> That assumes we guarantee that the image-directory is always first. That
> appears to be the case now. I think I'd be a little leery about
> committing to this in case we find out later that we needed to preserve
> the existing order in the path if the image directory was already in the
> path. But if we want to commit to this, then I'll add it to the
> documentation and use this example, otherwise...

After a little more thought, the idea of committing to this API isn't as
bad as I had initially thought. Functions like add-to-list do it. After
all, this function is supposed to set things up so the preferred images
are used, and that's done by putting the image directory first in the
path.

Unless I hear an objection this morning, I'll go ahead and make that
change (document that the image directory comes first and update the
example per Rainer's note). I'll also check it into image.el and send
out a note to emacs-devel about it (unless someone thinks I should send
a note to emacs-devel beforehand).

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

Re: image-load-path/load-path function

[Bill Wohler]

Bill Wohler <wohler@newt.com> wrote:

> Bill Wohler <wohler@newt.com> wrote:
> 
> > Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> > 
> > > On Fri, Mar 03 2006, Bill Wohler wrote:
> > > 
> > > But maybe we can suggest an example which avoids calling
> > > `image-load-path-for-library' twice:
> > > 
> > > (let* ((load-path (image-load-path-for-library "mh-e" "mh-logo.xpm"))
> > >        (image-load-path (cons (car load-path) image-load-path)))
> > >   ;; do something.  Test:
> > >   image-load-path)
> > 
> > That assumes we guarantee that the image-directory is always first. That
> > appears to be the case now. I think I'd be a little leery about
> > committing to this in case we find out later that we needed to preserve
> > the existing order in the path if the image directory was already in the
> > path. But if we want to commit to this, then I'll add it to the
> > documentation and use this example, otherwise...
> 
> After a little more thought, the idea of committing to this API isn't as
> bad as I had initially thought. Functions like add-to-list do it. After
> all, this function is supposed to set things up so the preferred images
> are used, and that's done by putting the image directory first in the
> path.
> 
> Unless I hear an objection this morning, I'll go ahead and make that
> change (document that the image directory comes first and update the
> example per Rainer's note). I'll also check it into image.el and send
> out a note to emacs-devel about it (unless someone thinks I should send
> a note to emacs-devel beforehand).

Rats, I forgot about this. Still, I would have liked to have gotten more
feedback before proceeding--shall we leave the function alone now, or
shall we make this change?

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


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

Re: image-load-path/load-path function

[Bill Wohler]

Bill Wohler <wohler@olgas.newt.com> wrote:

> Here is the same thing as my last patch, but now wrapped in a
> mh-defun-compat.

Just checked it in. Now in mh-compat.el instead of mh-utils.el. Updated
the example per one of your comments, but waiting to get feedback before
committing to the fact that the image directory is first before
modifying further.

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

Re: image-load-path/load-path function

[Reiner Steib]

On Thu, Mar 02 2006, Bill Wohler wrote:

> I'll work on porting your posted version back to MH-E so that they
> will be as close together as possible.  If you've changed it since
> your post last Wednesday, please let me know

I've also renamed -path to -directory.  Here are the recent changes:

,----
| revision 7.17
| date: 2006/03/02 16:56:29;  author: rsteib;  state: Exp;  lines: +3 -3
| * gmm-utils.el (gmm-image-load-path): Mention ../etc search in doc
| string.
| [...]
| ----------------------------
| revision 7.15
| date: 2006/03/01 16:51:17;  author: rsteib;  state: Exp;  lines: +34 -15
| [...]
| 
| * gmm-utils.el (gmm-image-directory): Rename variable from
| gmm-image-load-path.
| (gmm-image-load-path): Use gmm-image-directory.
| [...]
| ----------------------------
| revision 7.13
| date: 2006/02/23 13:19:13;  author: yamaoka;  state: Exp;  lines: +6 -4
| (gmm-image-load-path): Don't modify image-load-path and load-path.
| ----------------------------
| revision 7.12
| date: 2006/02/22 14:45:52;  author: rsteib;  state: Exp;  lines: +14 -5
| [...]
|
| * gmm-utils.el (gmm-image-load-path): Also search in
| "../etc/images".  Don't set gmm-image-load-path if we don't find
| the image.
`----

> (maybe sending me the URL to the file in your repository might be a
> good idea,

I'd recommend to check out `gmm-utils.el' from cvs:

$ cvs -d :pserver:gnus@cvs.gnus.org:/usr/local/cvsroot login
CVS password: gnus
$ cvs -d :pserver:gnus@cvs.gnus.org:/usr/local/cvsroot checkout gnus/lisp/gmm-utils.el

(cf. http://www.gnus.org/distribution.html)

There's also a cvsweb thingie, but when starting from
<http://quimby.gnus.org/cgi-bin/cvsweb.cgi/gnus/> the "(download)"
links don't work ATM.  You need to replace "/~checkout/~gnus/" with
"/~checkout~gnus/" (delete the "/"):

http://quimby.gnus.org/cgi-bin/cvsweb.cgi/~checkout~gnus/lisp/gmm-utils.el?content-type=text/plain

The diff functionality seems to work.  But of course I'd prefer to use
Emacs' version control facilities. :-)

[ From a later post...]

On Thu, Mar 02 2006, Peter S Galbraith wrote:

> Bill Wohler <wohler@newt.com> wrote:
>
>> Since it was Peter and Debian which suggested the use of this variable
>> in the first place, and now that the function checks both load-path and
>> image-load-path for the library's images, I'd like to ask Peter if it
>> would be OK to change the line in emacsen-startup:
>> 
>>   (setq mh-image-directory "/usr/share/emacs/site-lisp/etc/images/mh-e")
>> 
>> to
>> 
>>   (if (boundp 'image-load-path)
>>       (add-to-list 'image-load-path
>>                    "/usr/share/emacs/site-lisp/etc/images/mh-e")
>>     (add-to-list 'load-path "/usr/share/emacs/site-lisp/etc/images/mh-e"))
>> 
>> Is this called late enough so that
>> /usr/share/emacs/site-lisp/etc/images/mh-e would be placed in front of
>> the standard images directory?
>
> Yes it would be.  I can do that for the next release.


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


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

Re: image-load-path/load-path function

[Bill Wohler]

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

> I'd recommend to check out `gmm-utils.el' from cvs:

OK.

> On Thu, Mar 02 2006, Peter S Galbraith wrote:
> 
> > Bill Wohler <wohler@newt.com> wrote:
> >
> >> Since it was Peter and Debian which suggested the use of this variable
> >> in the first place, and now that the function checks both load-path and
> >> image-load-path for the library's images, I'd like to ask Peter if it
> >> would be OK to change the line in emacsen-startup:
> >> 
> >>   (setq mh-image-directory "/usr/share/emacs/site-lisp/etc/images/mh-e")
> >> 
> >> to
> >> 
> >>   (if (boundp 'image-load-path)
> >>       (add-to-list 'image-load-path
> >>                    "/usr/share/emacs/site-lisp/etc/images/mh-e")
> >>     (add-to-list 'load-path "/usr/share/emacs/site-lisp/etc/images/mh-e"))
> >> 
> >> Is this called late enough so that
> >> /usr/share/emacs/site-lisp/etc/images/mh-e would be placed in front of
> >> the standard images directory?
> >
> > Yes it would be.  I can do that for the next release.

This note escaped your MUA before you had a chance to comment on 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.

Re: Customizable tool bars

[Reiner Steib]

On Wed, Feb 22 2006, Katsumi Yamaoka wrote:

>>>>>> In <v9r75wnygh.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:
>
>> The new icons have been committed.  Thanks to Bill Wohler for the
>> discussion on sharing icons with MH-E and to Adam Sjøgren for
>> preparing some icons.
>
> Thank you for installing good features.  The Gnome icons work
> fine so far (they look to me somewhat gaudy, though I will get
> used to them sooner or later ;-).

I'm sure you will.

> However, the default retro icons didn't appear in the toolbars.
> I've modified icon files specified in `gnus-group-tool-bar-retro'
> and `gnus-summary-tool-bar-retro' so that they might be under
> the "gnus/" subdirectory.  Is it a proper change?

I think so.  Good that we live in different time zones, so you can fix
my late-evening mistakes while I sleep before other users in my time
zone even notice the breakage.  :-)

>> I think I will enable the new tool bars by default within the next
>> days.
>
> I think making the new feature the default is a good idea.

Thanks for your comments.

>> Maybe only on Emacs 22 and/or depending on the color capacities
>> of the display.  In Emacs 21, you currently get a mixture of old
>> Emacs-21-icons and new GNOME-style icons.

I think we also need to add prev/next (and maybe others; I need to
check) icons to Gnus CVS, because Emacs 21 doesn't have them.

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

Re: Customizable tool bars

[Reiner Steib]

On Wed, Feb 22 2006, Katsumi Yamaoka wrote:

> Reiner Steib wrote:
>> I think I will enable the new tool bars by default within the next
>> days.
>
> I think making the new feature the default is a good idea.

The new tool bars are now the default if (> (display-color-cells) 256).

For some reason Emacs 21 returns nil for that whereas Emacs 22 returns
t on the same display.  Any ideas?

ELISP> (display-color-cells)
64
ELISP> emacs-version
"21.3.3"

ELISP> (display-color-cells)
65536
ELISP> emacs-version
"22.0.50.5"

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

Re: Customizable tool bars

[Romain Francoise]

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

> For some reason Emacs 21 returns nil for that whereas Emacs 22 returns
> t on the same display.  Any ideas?

See the thread starting here:

   <URL: http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-02/msg00246.html>

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Customizable tool bars

[Reiner Steib]

On Wed, Mar 01 2006, Romain Francoise wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
>> For some reason Emacs 21 returns nil for that whereas Emacs 22 returns
>> t on the same display.  Any ideas?
>
> See the thread starting here:
>
>    <URL: http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-02/msg00246.html>
[ Or http://thread.gmane.org/gmane.emacs.pretest.bugs/2226 ]

Thanks.  It seems that (ash 1 (x-display-planes)) mentioned there
gives more appropriate result compared to `display-color-cells'.

Now I use `display-visual-class' which seems to work correctly for
Emacs 21 and Emacs 22 on 8-bit and 16-bit color depths.

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

Re: Customizable tool bars

[Michael Piotrowski]

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

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

> The new tool bars are now the default if (> (display-color-cells) 256).
>
> For some reason Emacs 21 returns nil for that whereas Emacs 22 returns
> t on the same display.  Any ideas?

No ideas about that, but XEmacs has `device-color-cells' instead of
`display-color-cells'.  To be able to start Gnus, I changed
gmm-utils.el like this:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Use `device-color-cells' on XEmacs --]
[-- Type: text/x-patch, Size: 688 bytes --]

Index: lisp/gmm-utils.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gmm-utils.el,v
retrieving revision 7.15
diff -C2 -r7.15 gmm-utils.el
*** lisp/gmm-utils.el	1 Mar 2006 16:51:17 -0000	7.15
--- lisp/gmm-utils.el	1 Mar 2006 19:29:25 -0000
***************
*** 177,181 ****
  			  (symbol :tag "Icon item")))))
  
! (defcustom gmm-tool-bar-style (if (> (display-color-cells) 256)
  				  'gnome
  				'retro)
--- 177,183 ----
  			  (symbol :tag "Icon item")))))
  
! (defcustom gmm-tool-bar-style (if (> (if (featurep 'xemacs)
! 					 (device-color-cells)
! 				       (display-color-cells)) 256)
  				  'gnome
  				'retro)

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


I don't know whether this is the best solution, but it works for me.
I noticed that it `device-color-cells' returns 256 even though I've
got 24 bit color depth, but frankly, I don't care since I'm using my
own text-only toolbar anyway ;-)

Greetings

-- 
Michael Piotrowski, M.A.                               <mxp@dynalabs.de>
Public key at <http://www.dynalabs.de/mxp/pubkey.txt>

Re: Customizable tool bars

[Reiner Steib]

On Wed, Mar 01 2006, Michael Piotrowski wrote:

> No ideas about that, but XEmacs has `device-color-cells' instead of
> `display-color-cells'.  

`gmm-tool-bar-style' is not used in XEmacs, but I overlooked that
`gmm-utils.el' is loaded anyhow.  Sorry.

`device-color-cells' might also return nil so we need a slightly
different fix.  I will look into it tomorrow unless someone else fixes
it in the meantime.

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

Re: Customizable tool bars

[Katsumi Yamaoka]

>>>>> In <x6k6be9cvy.fsf@eurus.mag.dynalabs.de> Michael Piotrowski wrote:

> No ideas about that, but XEmacs has `device-color-cells' instead of
> `display-color-cells'.  To be able to start Gnus, I changed
> gmm-utils.el like this:

[...]

> ! (defcustom gmm-tool-bar-style (if (> (if (featurep 'xemacs)
> ! 					 (device-color-cells)
> ! 				       (display-color-cells)) 256)
>   				  'gnome
>   				'retro)

`device-color-cells' returns nil when XEmacs runs with -batch or
-nw option.  So it should be:

--8<---------------cut here---------------start------------->8---
--- gmm-utils.el~	2006-03-01 21:46:53 +0000
+++ gmm-utils.el	2006-03-01 23:42:12 +0000
@@ -176,7 +176,9 @@
 			  :tag "Other"
 			  (symbol :tag "Icon item")))))
 
-(defcustom gmm-tool-bar-style (if (> (display-color-cells) 256)
+(defcustom gmm-tool-bar-style (if (> (if (featurep 'xemacs)
+					 (or (device-color-cells) 0)
+				       (display-color-cells)) 256)
 				  'gnome
 				'retro)
   "Prefered tool bar style."
--8<---------------cut here---------------end--------------->8---

> I don't know whether this is the best solution, but it works for me.
> I noticed that it `device-color-cells' returns 256 even though I've
> got 24 bit color depth, but frankly, I don't care since I'm using my
> own text-only toolbar anyway ;-)

I also am not sure whether counting colors is proper way, so I
refrain from installing it for the moment.

Re: Customizable tool bars

[Michael Piotrowski]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> `device-color-cells' returns nil when XEmacs runs with -batch or
> -nw option.  So it should be:

[...]

Yes, that's right.

>> I don't know whether this is the best solution, but it works for me.
>> I noticed that it `device-color-cells' returns 256 even though I've
>> got 24 bit color depth, but frankly, I don't care since I'm using my
>> own text-only toolbar anyway ;-)
>
> I also am not sure whether counting colors is proper way, so I
> refrain from installing it for the moment.

The most important point for me is that a customize option which
apparently doesn't even apply to XEmacs shouldn't break Gnus on
XEmacs.

-- 
Michael Piotrowski, M.A.                               <mxp@dynalabs.de>
Public key at <http://www.dynalabs.de/mxp/pubkey.txt>

Re: Customizable tool bars

[Reiner Steib]

On Thu, Mar 02 2006, Michael Piotrowski wrote:

> The most important point for me is that a customize option which
> apparently doesn't even apply to XEmacs shouldn't break Gnus on
> XEmacs.

I already wrote earlier that I'll fix this ASAP.  If you can't live
with occasional breakage (especially on XEmacs which is not used by
most Gnus developers), you should better not use the CVS version of
Gnus for your daily work.  I don't have the resources to test every
Gnus change on XEmacs (and each and every MULE/no-MULE/--with-whatever
variant) myself.

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

Re: Customizable tool bars

[Michael Piotrowski]

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

> On Thu, Mar 02 2006, Michael Piotrowski wrote:
>
>> The most important point for me is that a customize option which
>> apparently doesn't even apply to XEmacs shouldn't break Gnus on
>> XEmacs.
>
> I already wrote earlier that I'll fix this ASAP.  If you can't live
> with occasional breakage (especially on XEmacs which is not used by
> most Gnus developers), you should better not use the CVS version of
> Gnus for your daily work.  I don't have the resources to test every
> Gnus change on XEmacs (and each and every MULE/no-MULE/--with-whatever
> variant) myself.

I didn't mean to criticize you and I'm sorry if it sounded like I
would.  I'm fully aware that CVS Gnus might be borken sometimes.

I was actually referring to Katsumi Yamaoka's comment ("I also am not
sure whether counting colors is proper way, so I refrain from
installing it for the moment.").  In fact I intended to say two
things:

1. Even if counting color cells may not be the right way, it may be
   good to fix portability problems early.

2. If the whole setting only applies to GNU Emacs, conditionally using
   `device-color-cells' instead of `display-color-cells' doesn't
   really make sense, and maybe the whole defcustom should not be
   evaluated on XEmacs.  A crude implementation could be something
   like this:

   (if (not (featurep 'xemacs)) ; This setting doesn't apply to XEmacs
       (defcustom gmm-tool-bar-style (if (> (display-color-cells) 256)
                                         'gnome
                                       'retro)
         "Prefered tool bar style."
         :type '(choice (const :tag "GNOME style" 'gnome)
                        (const :tag "Retro look"  'retro))
         :group 'gmm))

   But I'm not sure how much of Gmm is GNU Emacs-specific, so a good
   solution may look different.

I admit I should have written this in the first place ;-)

Greetings

-- 
Michael Piotrowski, M.A.                               <mxp@dynalabs.de>
Public key at <http://www.dynalabs.de/mxp/pubkey.txt>

Re: Customizable tool bars

[Katsumi Yamaoka]

>>>>> In <v9r75m12rs.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

> The new tool bars are now the default if (> (display-color-cells) 256).

> For some reason Emacs 21 returns nil for that whereas Emacs 22 returns
> t on the same display.  Any ideas?

I don't have an idea, but...

ELISP> (display-color-cells)
> 64
ELISP> emacs-version
> "21.3.3"

ELISP> (display-color-cells)
> 65536
ELISP> emacs-version
> "22.0.50.5"

In my Linux box,
Emacs 21.1, 21.2 and 21.4
 => 256
Emacs 22.0.50 and 23.0.0
 => 16777216
XEmacs 21.4.19 and 21.5-b25 (using `device-color-cells')
 => 256

Are 256 colors insufficient to display Gnome icons?

Re: Customizable tool bars

[Reiner Steib]

On Wed, Mar 01 2006, Katsumi Yamaoka wrote:

> Emacs 21.1, 21.2 and 21.4
>  => 256
> Emacs 22.0.50 and 23.0.0
>  => 16777216
> XEmacs 21.4.19 and 21.5-b25 (using `device-color-cells')
>  => 256
>
> Are 256 colors insufficient to display Gnome icons?

Assuming that those values were correct: Yes, 256 colors (8 bit color
depth) is insufficient.  I didn't count the number of colors in the
icons [1], but 256 colors get exhausted *very* soon.

You can try it with...

X :1 -depth 8 &
twm -display :1 &
xterm -display :1 &
emacs -display :1  &

Set `gmm-tool-bar-style' to 'gnome, start gnus-slave.  Already here
the colors in the icons are reduced AFAICS.

Then start e.g. gv:

Warning: Cannot allocate colormap entry for "AntiqueWhite3"
Warning: Cannot allocate colormap entry for "AntiqueWhite2"
Warning: Cannot allocate colormap entry for "AntiqueWhite4"
Warning: Cannot allocate colormap entry for "gray40"
Warning: Cannot allocate colormap entry for "gray78"
Warning: Cannot allocate colormap entry for "#D3B5B5"

Close gv, start firefox.  You'll see that it uses a private colormap
for it's windows.

BTW, both Emacs 21 and Emacs 22 reported 256 (correct) on the 8-bit
display.  I don't know how to get the correct information for > 8-bit
from Emacs 21.  (I didn't follow the URL given by Romain yet -- I'm
offline).  But even if there is no technical possibility in Emacs 21,
the user can simply customize a single variable `gmm-tool-bar-style'
to get Gnome icons (this was one of the main reasons why I introduced
it).

Bye, Reiner.

[1] Just some approximate values:

etc/images$ grep -h '^".*#[0-9]*",$' *.xpm|sort -k3,3 -u|wc -l
296

etc/images/mail$ grep -h '^".*#[0-9]*",$' *.xpm|sort -k3,3 -u|wc -l
181
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Customizable tool bars

[Katsumi Yamaoka]

>>>>> In <v9zmk9nmsy.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib wrote:

> On Wed, Mar 01 2006, Katsumi Yamaoka wrote:

>> Emacs 21.1, 21.2 and 21.4
>>  => 256
>> Emacs 22.0.50 and 23.0.0
>>  => 16777216
>> XEmacs 21.4.19 and 21.5-b25 (using `device-color-cells')
>>  => 256
>>
>> Are 256 colors insufficient to display Gnome icons?

Well, Emacs 21 and XEmacs don't seem to tell the truth.  Those
Emacsen display pictures and icons beautifully, but I know how
the 8-bit pseudo color terminal does.  Anyway, now Emacs 21
displays Gnome icons on the Gnus frames by default because
`display-visual-class' returns `true-color'.  No problem.

> Assuming that those values were correct: Yes, 256 colors (8 bit color
> depth) is insufficient.  I didn't count the number of colors in the
> icons [1], but 256 colors get exhausted *very* soon.

> You can try it with...

> X :1 -depth 8 &
> twm -display :1 &
> xterm -display :1 &
> emacs -display :1  &

Oh, I didn't know such a way.

> Set `gmm-tool-bar-style' to 'gnome, start gnus-slave.  Already here
> the colors in the icons are reduced AFAICS.

> Then start e.g. gv:

> Warning: Cannot allocate colormap entry for "AntiqueWhite3"
> Warning: Cannot allocate colormap entry for "AntiqueWhite2"
> Warning: Cannot allocate colormap entry for "AntiqueWhite4"
> Warning: Cannot allocate colormap entry for "gray40"
> Warning: Cannot allocate colormap entry for "gray78"
> Warning: Cannot allocate colormap entry for "#D3B5B5"

> Close gv, start firefox.  You'll see that it uses a private colormap
> for it's windows.

I see.  I recalled I was often troubled with them in old days.

> BTW, both Emacs 21 and Emacs 22 reported 256 (correct) on the 8-bit
> display.  I don't know how to get the correct information for > 8-bit
> from Emacs 21.  (I didn't follow the URL given by Romain yet -- I'm
> offline).  But even if there is no technical possibility in Emacs 21,
> the user can simply customize a single variable `gmm-tool-bar-style'
> to get Gnome icons (this was one of the main reasons why I introduced
> it).

How about adding the toggle button to the toolbat itself?  It
switches Gnome, Retro, and the default Emacs buttons. ;-)

Re: Customizable tool bars

[Reiner Steib]

On Fri, Mar 03 2006, Katsumi Yamaoka wrote:

> How about adding the toggle button to the toolbat itself?

The default tool bar should contain only the most important and
frequently used commands.  I hope that nobody wants to do that
frequently now that e have nice tool bars.  :-)

> It switches Gnome, Retro, and the default Emacs buttons. ;-)

`M-x customize-set-variable RET gnus-summary-tool-bar RET Retro look RET'
(and -group-) works, but the same for message doesn't: The new setting
only applies to new message buffers.  There is no simple functionality
to restore the Emacs default tool bar yet.

If you think that such a toggle would be useful, feel free to add it
to the *-tool-bar-gnome defcustoms, leaving it invisible by default.

BTW, some modes might also deserve improved tool bars:

- gnus-draft-mode

- mml-preview buffer:

  • zap most buttons; except print, customize (?) and help

  • "exit" should just kill the buffer

- gnus-server-mode: Add some commands from the Connections and Server
  menu.

- gnus-browse-mode (could borrow some icons from gnus-group-mode)

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

Re: Customizable tool bars

[Katsumi Yamaoka]

>>>>> In <v91wxjddep.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Fri, Mar 03 2006, Katsumi Yamaoka wrote:

>> How about adding the toggle button to the toolbat itself?

> The default tool bar should contain only the most important and
> frequently used commands.  I hope that nobody wants to do that
> frequently now that e have nice tool bars.  :-)

I agree.

[...]

> BTW, some modes might also deserve improved tool bars:

> - gnus-draft-mode

> - mml-preview buffer:

>   • zap most buttons; except print, customize (?) and help

>   • "exit" should just kill the buffer

> - gnus-server-mode: Add some commands from the Connections and Server
>   menu.

> - gnus-browse-mode (could borrow some icons from gnus-group-mode)

I'd like to add one more item to this todo list.

- Make XEmacs be able to display Gnome icons as well.

Re: Customizable tool bars

[Reiner Steib]

On Mon, Mar 06 2006, Katsumi Yamaoka wrote:

> I'd like to add one more item to this todo list.
>
> - Make XEmacs be able to display Gnome icons as well.

Gnome icons would look like aliens beside the standard XEmacs icons,
IMHO.

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

Re: Customizable tool bars

[Katsumi Yamaoka]

>>>>> In <v9bqwj6eza.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib wrote:

> On Mon, Mar 06 2006, Katsumi Yamaoka wrote:

>> I'd like to add one more item to this todo list.
>>
>> - Make XEmacs be able to display Gnome icons as well.

> Gnome icons would look like aliens beside the standard XEmacs icons,
> IMHO.

I think so.  But that is just what I felt with Gnome icons for
Gnus on Emacs at the first time;-p  At any rate, I have neither
the will to do it aggressively nor time so much for the moment.

low-color variants of the Gnome icons (was: Customizable tool bars)

[Reiner Steib]

[ Adding mh-e-devel ]

On Fri, Mar 03 2006, Katsumi Yamaoka wrote:

>>>>>> In <v9zmk9nmsy.fsf@marauder.physik.uni-ulm.de>
>>>>>>	Reiner Steib wrote:
[ `display-color-cells' reports 256 in Emacs 21 ]
> Well, Emacs 21 and XEmacs don't seem to tell the truth.  

Correct.

> Those Emacsen display pictures and icons beautifully, but I know how
> the 8-bit pseudo color terminal does.  Anyway, now Emacs 21 displays
> Gnome icons on the Gnus frames by default because
> `display-visual-class' returns `true-color'.  No problem.

In Emacs 22, `tool-bar-local-item' looks for (concat "low-color/" icon
".xpm") so if someone would convert the new icons to low-color
variants (see etc/image/low-color/ in Emacs 22), we could use those
instead of falling back to the retro tool bars.

I guess this should be quite easy for someone skilled in using Gimp
(maybe automatically).  But I couldn't even find how to "convert to
indexed" in Gimp as suggested by Jan D.:

,----[ http://article.gmane.org/gmane.emacs.devel/35176 ]
| From: Jan D. <jan.h.d <at> swipnet.se>
| Subject: Re: Toolbar: Suggestion for improved dired icon.
| Newsgroups: gmane.emacs.devel
| Date: 2005-03-25 23:11:23 GMT
|
| >>Just don't forget to reduce the colors some more, ideally not more
| >>than hundred.  Otherwise people running on 8 bit displays will run
| >>out.  When reducing colors, avoid dithering, it looks bad on icons
| >>this small.  And use the same palette as for the other icons also,
| >>so the sum of colors Emacs uses doesn't increase (it is on the limit
| >>for 8 bit displays already).
| >
| >Did you do the conversion manually, or did you use some special tool
| >for it?  Actually, this is a stupid question since you probably did
| >not use pencil and paper.  So what tool did you use, and how?
| 
| 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.
`----

I guess that we need the steps described above for the low-color
xpm icons and the following steps for the pbm icons:

,----[ http://article.gmane.org/gmane.mail.mh-e.devel/11687 ]
| In case you find it useful, I got the following tip for creating
| Emacs-compatible .pbm images from jan.h.d <at> 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.
`----

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