bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#71162: address@hidden


From: Eli Zaretskii
Subject: bug#71162: address@hidden
Date: Sat, 25 May 2024 09:09:23 +0300

[Please use Reply All to reply, to keep the bug tracker CC'ed.]

> Date: Fri, 24 May 2024 12:29:49 -0700
> From: David McCracken <davidm@ixont.com>
> 
> I use the same icons and emacs code on Windows and Linux. In Windows it 
> works in Emacs 29.1 and 26.1 (the two I currently use but it worked in 
> older versions as well). In Ubuntu-Mate (20.54 and 22.04) it works in 
> Emacs 26.3 but not 27.1. The code I use for this particular example is
> 
> (define-key-after (default-value 'tool-bar-map)
>    [separator-4] menu-bar-separator)
> ; Linux-Emacs v25 includes pseudo-key name in the toolbar unless it is too
> ; long, which is the only way to stop this unwanted behavior.
> (tool-bar-add-item "~/icons/lxa-next"
>    'lxa-next
>    'lxa-next-reference
>    :help "LXA next reference")
> 
> In all cases except Emacs 27.1 in Linux the user icons directory is not 
> a problem. However, it is an additional problem in 27.1 under Linux. The 
> same native lock-broken.xpm that works when in the images directory and 
> referenced simply as "lock-broken" fails when moved to the user icons 
> directory and referenced as "~/icons/lock-broken". 27.1 also ignores my 
> lxa-next.xpm when moved to the images directory and referenced simply as 
> "lxa-next". Somebody hard-wired all flexibility out of this mechanism 
> after 26.3 but only in the Linux version. I initially suspected the 
> changes related to B/W pbm images, which is described in the images 
> README but I found the same README in 26.3.

If you visit (with C-x C-f) the lxa-next.xpm file in Emacs 27.1 on
Ubuntu, does it display correctly as an image?  If not, your Emacs
27.1 on Ubuntu is for some reason unable to display XPM images.

If lxa-next.xpm does display correctly on Ubuntu, then you need to
find out why adding a tool-bar button with an XPM image doesn't work
for you.  I just tried the below in "emacs-Q" (using Emacs 27.1), and
it did show the additional tool-bar button:

  (defun lxa-next ()
    (interactive)
    (message "lxa-next"))

  (tool-bar-add-item "~/icons/lxa-next"
   'lxa-next
   'lxa-next-reference
   :help "LXA next reference")

Does the above work for you in "emacs -Q" on Ubuntu?

If it works in "emacs -Q", but not in your regular sessions, then
there are some customizations, perhaps site-wide and possibly by the
Ubuntu distro, which somehow prevent this.  In the upstream sources, I
see no changes in this area.  tool-bar-add-item still ends up calling
tool-bar--image-expression, which calls find-image like this:

  (let* ((fg (face-attribute 'tool-bar :foreground))
         (bg (face-attribute 'tool-bar :background))
         (colors (nconc (if (eq fg 'unspecified) nil (list :foreground fg))
                        (if (eq bg 'unspecified) nil (list :background bg))))
         (xpm-spec (list :type 'xpm :file (concat icon ".xpm")))
         (xpm-lo-spec (list :type 'xpm :file
                            (concat "low-color/" icon ".xpm")))
         (pbm-spec (append (list :type 'pbm :file
                                 (concat icon ".pbm")) colors))
         (xbm-spec (append (list :type 'xbm :file
                                 (concat icon ".xbm")) colors)))
    `(find-image (cond ((not (display-color-p))
                        ',(list pbm-spec xbm-spec xpm-lo-spec xpm-spec))
                       ((< (display-color-cells) 256)
                        ',(list xpm-lo-spec xpm-spec pbm-spec xbm-spec))
                       (t
                        ',(list xpm-spec pbm-spec xbm-spec))))))

As you see here, if your display can support at least 256 colors, the
XPM image gets preference over the other possibilities.  And
find-image searches for the image file via image-search-load-path,
which searches image-load-path, and for absolute file names like
"~/images/lxa-next" should find the file immediately regardless of the
value of image-load-path.

So if your Emacs does not have some customizations, it should find the
images without any problem.

If the problem is some Ubuntu customizations, you should take that up
with the Ubuntu distro maintainers; we here are only responsible for
the original Emacs 27.1 tarball.

> In case you are interested I have attached my complete code.

I attach it below, because you sent the response only to me in private
email (please use Reply All or "wide reply" in your future responses
to this discussion).

Attachment: linkxall.el
Description: application/emacs-lisp


reply via email to

[Prev in Thread] Current Thread [Next in Thread]