[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Toolbar and transparent icons
>>>>> In [emacs-w3m : No.09315] Leo wrote:
> On 2007-03-29, Katsumi Yamaoka said:
>>> I think maybe there is a bug in emacs-w3m. Ideas?
>> I don't recommend using PNG iocns for LUCID Emacs. Because, AFAIK,
>> Emacs supports transparent colors for only XPM images. Note that
>> GTK is not a part of Emacs.
Let me write more about this. Even now I have no doubt about a
fact that Emacs doesn't support displaying transparent colors of
PNG images. OTOH, that GTK toolbars support it is also a fact.
As for XPM images, GTK toolbars and Emacs buffers support
transparent colors. Actually both LUCID Emacs and GTK Emacs use
XPM icons for toolbars by default. However, there is a
restriction which prevents same XPM files from being shared by
GTK Emacs and XEmacs. While a transparent color has to be
"X c None"
for GTK toolbars, it has to be in the following style for XEmacs:
"X c #FFFFFF s backgroundToolBarColor"
You can see this difference by looking into files installed in
the etc/images/gnus/ directory. For instance, exit-gnus.xpm is
for Emacs, gnus-group-exit-up.xpm is for XEmacs. LUCID Emacs'
toolbars support both the styles, so all the XPM icon files of
emacs-w3m use the later style.
> The fact that the default toolbar can
Do you really use PNG images for the default toolbar in LUCID
Emacs? There's no PNG file used for toolbars in the Emacs CVS
source tree. In my LUCID Emacs, it uses XPM icons as follows:
| tool-bar-map is a variable defined in\
| (new-file menu-item "Visit New File..." find-file
| ([24 6]
| . " (C-x C-f)")
| :help "Specify a new file's name, to edit the file" :image
| (image :type xpm :file\
> while w3m can not display transparent png icons in Emacs with Lucid
> toolkit is a little bit strange.
I repeatedly write that I don't recommend using PNG icons for
LUCID Emacs. I'd programmed the
`w3m-toolbar-icon-preferred-image-types' variable so that it
might have the value `(xpm)' by default for LUCID Emacs.
> Our previous discussion seems to conclude it is a bug in Emacs but
> maybe it is a bug in w3m was my question.
I don't think emacs-w3m has a bug.