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

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

bug#71162: address@hidden


From: David McCracken
Subject: bug#71162: address@hidden
Date: Sat, 25 May 2024 12:08:33 -0700
User-agent: Mozilla Thunderbird

Thank you both for taking the time to look into this.

I use Gimp under Windows to make my icons and they all work in Linux-Emacs 26.1. When I open lxa-next.xpm in Linux-Emacs 26.3 (in Ubuntu-Mate 20.54) the icon is rendered correctly. Linux-Emacs 27.1 (in Ubuntu-Mate 22.04) shows it as a blank box. All systems correctly show my icons in the GUI. I edited lxa-next.xpm as text, completely removing the Windows directory, which isn't proper C code because it doesn't name the variable being defined. Nevertheless, the newer Linux computer's GUI does render it although with less saturated colors. When I include a variable name, "something" or "*/~/icons/lxa-next.xpm", the system renders it as designed. However, Emacs still shows it blank. I tried all of these variations in the 27.1/etc/images directory and Emacs showed them all blank. This did not change with emacs -q so the problem is not caused by my .emacs. The problem also doesn't seem to be caused by Ubuntu-Mate because it renders my icons correctly.

I assume that tool-bar--image-expression is located in an elc module. Which is it and can I get an el copy? I would like to trace it to determine why Linux-Emacs 27.1 refuses its own icons unless located in 27.1/etc/images. That it refuses my icons no matter where they are located may be related. With some help from you all I may be able to find the root of both problems.

On 2024-05-24 11:09 PM, Eli Zaretskii wrote:
[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).






reply via email to

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