5:05 a.m.
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!
Please write in English, because the XEmacs maintainers do not have
translators to read other languages for them.
Please describe as succinctly as possible:
- What happened.
- What you thought should have happened.
- Precisely what you were doing at the time.
Please also include any C or lisp back-traces that you may have.
================================================================
Dear Bug Team!
I have the following code in my init.el file:
;; -------
;; Pointer used during garbage collection.
;; .xbm not supported under windoze
(if (and (file-exists-p "~/.xemacs/recycle-image.xbm")
(file-exists-p "~/.xemacs/recycle-mask.xbm")
(not running-windoze))
(set-glyph-image gc-pointer-glyph
(vector 'xbm
:file "~/.xemacs/recycle-image.xbm"
:mask-file "~/.xemacs/recycle-mask.xbm"
:foreground "black"
:background "chartreuse1"))
(set-glyph-image gc-pointer-glyph "recycle2.xpm"))
This worked great for, well years. However, I noticed recently that I
no longer get the recycle icon, I get a text message instead. If I use
the "recycle2.xpm" icon instead, I get an icon but it is black, not
green.
I tried it with -vanilla, but no change.
Has anything changed in xbm/xpm support?
Cheers,
Sean MacLennan
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: Linux fillmore.seanm.ca 2.4.16 #5 Mon Nov 26 23:29:10 EST 2001 i686 unknown
./configure '--package-path=/home/xemacs/packages:~/.xemacs'
'--with-sound=noesd,native' '--without-ipv6-cname'
XEmacs 21.4.6 "Common Lisp" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /home/xemacs/xemacs-21.4
Installation prefix: /usr/local
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -g -O3 -Wall -Wno-switch -Winline
-Wmissing-prototypes -Wsign-compare -Wshadow
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Compiling in support for X-Face message headers.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for PostgreSQL.
- Using PostgreSQL header file: pgsql/libpq-fe.h
- Using PostgreSQL V7 bindings.
Internationalization:
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Load-Path Lisp Shadows:
----------------------
nil
Installed XEmacs Packages:
-------------------------
((site-lisp:version 1.0 :type single)
(xemacs-devel :version 1.43 :type single-file)
(xemacs-base :version 1.61 :type regular)
(vm :version 7.03 :type regular)
(vc :version 1.3 :type regular)
(tramp :version 1.04 :type regular)
(toolbar-fancy :version 0.06 :type regular)
(time :version 1.11 :type regular)
(text-modes :version 1.4 :type single-file)
(speedbar :version 1.23 :type regular)
(sounds-au :version 1.1 :type regular)
(sh-script :version 1.14 :type regular)
(semantic :version 1.12 :type regular)
(psgml :version 1.27 :type regular)
(prog-modes
:version
1
.53
:type
single-file)
(pcomplete :version 1.01 :type regular)
(pcl-cvs :version 1.6 :type regular)
(pc :version 1.21 :type single-file)
(os-utils :version 1.26 :type single-file)
(oo-browser :version 4.5 :type regular)
(net-utils :version 1.24 :type single-file)
(mailcrypt :version 2.11 :type regular)
(mail-lib :version 1.44 :type regular)
(ispell :version 1.24 :type regular)
(igrep :version 1.08 :type regular)
(ibuffer :version 1.04 :type regular)
(gnus :version 1.59 :type regular)
(games :version 1.13 :type regular)
(fsf-compat :version 1.11 :type single-file)
(elib :version 1.1 :type single-file)
(eieio :version 1.02 :type regular)
(efs :version 1.28 :type regular)
(edit-utils :version 1.82 :type single-file)
(ediff :version 1.39 :type regular)
(edebug :version 1.14 :type regular)
(dired :version 1.11 :type regular)
(dictionary :version 1.08 :type regular)
(cookie :version 1.14 :type regular)
(cc-mode :version 1.27 :type regular)
(calendar :version 1.18 :type regular)
(c-support :version 1.16 :type single-file)
(bbdb :version 1.2 :type regular))
Features:
--------
(mail-abbrevs xemacsbug shadow sendmail rfc822 ws-trim gnuserv
filladapt backup tramp shell comint ring format-spec timer
browse-kill-ring overlay ediff-hook advice advice-preload uniquify
hide-copyleft font-lock-extras font-lock edmacro iswitchb efs-cu
slashdot browse-url http time cus-face big-menubar pending-del paren
blink-paren uncompress redo site-lisp-autoloads xemacs-devel-autoloads
xemacs-base-autoloads vm-autoloads vc-autoloads tramp-autoloads
toolbar-fancy-autoloads time-autoloads text-modes-autoloads
speedbar-autoloads sounds-au-autoloads sh-script-autoloads
semantic-autoloads psgml-autoloads prog-modes-autoloads
pcomplete-autoloads pcl-cvs-autoloads pc-autoloads os-utils-autoloads
oo-browser-autoloads net-utils-autoloads mailcrypt-autoloads
mail-lib-autoloads ispell-autoloads igrep-autoloads ibuffer-autoloads
gnus-autoloads games-autoloads fsf-compat-autoloads elib-autoloads
eieio-autoloads efs-autoloads edit-utils-autoloads ediff-autoloads
edebug-autoloads dired-autoloads dictionary-autoloads cookie-autoloads
cc-mode-autoloads calendar-autoloads c-support-autoloads
bbdb-autoloads lisp-autoloads loadhist auto-show fontl-hooks
x-iso8859-1 gutter-items menubar-items x-menubar mode-motion mouse
itimer auto-save lisp-mode easymenu iso8859-1 page buff-menu
lib-complete help-nomule cus-file derived frame text-props obsolete
cus-start custom widget cl-extra mini-cl cl cl-19 packages backquote
very-early-lisp postgresqlv7 postgresql lucid-scrollbars cut-buffer
lucid-menubars motif-dialogs x c-balloon-help tty-frames tty toolbar
native-sound scrollbar unix-processes multicast network-streams
subprocesses modules menu-accelerator-support menubar berkeley-db md5
xemacs gutter tiff png gif jpeg xface xpm xbm lisp-float-type linux
dialog devices window-system base64)
Recent keystrokes:
-----------------
M-x r e p o r t - x e m TAB RET
Recent messages (most recent first):
-----------------------------------
Loading xemacsbug...done
Loading xemacsbug...
Good morning Sean MacLennan
Loading gnuserv...done
Loading gnuserv...
Loading advice...done
Loading advice...
Loading edmacro...done
Loading edmacro...
Loading iswitchb...done
Loading iswitchb...
Loading cl-macs...done
Loading cl-macs...
Slashdot headings loaded.
Loading efs-cu...done
Loading efs-cu...
Loading time...done
Loading cus-face...done
Loading cus-face...
Loading time...
1:11 p.m.
>>>> "Sean" == Sean MacLennan
<seanm(a)seanm.ca> writes:
Sean> This worked great for, well years. However, I noticed
Sean> recently that I no longer get the recycle icon, I get a text
Sean> message instead. If I use the "recycle2.xpm" icon instead, I
Sean> get an icon but it is black, not green.
You've looked at the image files and they're ok? It's possible I
managed to bork them making a distro ... I'll look later.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
1:23 p.m.
>>>> "Sean" == Sean MacLennan
<seanm(a)seanm.ca> writes:
Sean> This worked great for, well years. However, I noticed
Sean> recently that I no longer get the recycle icon, I get a text
Sean> message instead. If I use the "recycle2.xpm" icon instead, I
Sean> get an icon but it is black, not green.
Sean> I tried it with -vanilla, but no change.
Sean> Has anything changed in xbm/xpm support?
I recently saw something similar under windows. The glyph was somehow
wrong - but to me it was with black lines randomly over it ... was
related to a new graphics card... I know this is linux you're running,
but it couldn't pssibly be something like that?
bye. Adam.
--
Adam Duck (duck(a)cs.uni-frankfurt.de)
Bockenheimer Landstr. 135 / Zi. 211
60325 Frankfurt/Main
______________________________________
I've learned that you can be in love with four girls at the same time.
--- age 9
4:44 p.m.
On Wed, 17 Apr 2002 00:05:37 EDT, Sean MacLennan <seanm(a)seanm.ca> said:
(set-glyph-image gc-pointer-glyph "recycle2.xpm"))
This worked great for, well years. However, I noticed recently that I
no longer get the recycle icon, I get a text message instead. If I use
the "recycle2.xpm" icon instead, I get an icon but it is black, not
green.
I'm seeing this as well, but haven't tracked it down as of yet.
My top contender for why it's screwed up:
1) If you're using a 16-bit visual, you could be running out of colormap
entries or similar - at least on my box, the default visual looks like this:
default visual id: 0x23
visual:
visual id: 0x23
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
Note that the green mask is 6 bits, but only 5 bits are available in
the colormap subfield - so it's possible to run out (I think). Depending
on window manager, and background images, your colormap may be running out.
I never really understood the semantics of how XAllocColor() is supposed to
work on a TrueColor visual in conjunction with colormaps, so....
I started seeing it (well, noticing anyhow) when I changed my was-showing-green X server
from a
1280x1024x24 config to a shows-black 1600x1200x16 config to support a bigger
monitor (the Intel i810 has a lame dot-clock with insufficient bandwidth to
do deeper than 16 bit at the higher resolution - the loss of color depth was
OK in exchange for 609,280 more pixels. ;)
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
5:07 p.m.
Valdis.Kletnieks(a)vt.edu wrote:
> (set-glyph-image gc-pointer-glyph
"recycle2.xpm"))
>
> This worked great for, well years. However, I noticed recently that I
> no longer get the recycle icon, I get a text message instead. If I use
> the "recycle2.xpm" icon instead, I get an icon but it is black, not
> green.
I'm seeing this as well, but haven't tracked it down as of yet.
My top contender for why it's screwed up:
1) If you're using a 16-bit visual, you could be running out of colormap
entries or similar - at least on my box, the default visual looks like this:
default visual id: 0x23
visual:
visual id: 0x23
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
Note that the green mask is 6 bits, but only 5 bits are available in
the colormap subfield - so it's possible to run out (I think). Depending
on window manager, and background images, your colormap may be running out.
I never really understood the semantics of how XAllocColor() is supposed to
work on a TrueColor visual in conjunction with colormaps, so....
I'm pretty sure that XAllocColor() just returns the closest colour on
"fixed" visuals (StaticGray, StaticColor, TrueColor). It only actually
"allocates" anything on visuals which have some form of programmable
look-up table (GrayScale, PseudoColor, DirectColor).
DirectColor is the case where I never managed to understand the
semantics of XAllocColor(). I'm not sure that anyone else does either;
every piece of code which I could find simply created a private
colourmap and initialised it to a ramp using XStoreColor().
--
Glynn Clements <glynn.clements(a)virgin.net>
1:52 a.m.
Stephen J. Turnbull writes:
>>>>> "Sean" == Sean MacLennan
<seanm(a)seanm.ca> writes:
Sean> This worked great for, well years. However, I noticed
Sean> recently that I no longer get the recycle icon, I get a text
Sean> message instead. If I use the "recycle2.xpm" icon instead, I
Sean> get an icon but it is black, not green.
You've looked at the image files and they're ok? It's possible I
managed to bork them making a distro ... I'll look later.
The .xbm files are my own. The .xpm file looks fine. It even comes out
right if I open it as a .xpm file in XEmacs.
As for the colour depth:
xwininfo: Window id: 0xe00037 "XEmacs 21.4.6 *scratch*"
Absolute upper-left X: 622
Absolute upper-left Y: 24
Relative upper-left X: 3
Relative upper-left Y: 3
Width: 654
Height: 985
Depth: 24
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x20 (installed)
Bit Gravity State: NorthWestGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsUnMapped
Override Redirect State: no
Corners: +622+24 -4+24 -4-15 +622-15
-geometry 90x72-1-12
Cheers,
Sean
3:49 p.m.
Glynn Clements <glynn.clements(a)virgin.net> wrote:
I'm pretty sure that XAllocColor() just returns the closest
colour on
"fixed" visuals (StaticGray, StaticColor, TrueColor). It only actually
"allocates" anything on visuals which have some form of programmable look-up
table (GrayScale, PseudoColor, DirectColor).
Correct. The cells are allocated read-only, can be shared by multiple
clients. The actual color spec used and returned is the closest one supported
by the hardware.
DirectColor is the case where I never managed to understand the
semantics of XAllocColor(). I'm not sure that anyone else does either;
Here's my understanding: in DirectColor, you think in terms of color
planes rather that in terms of color cells. For instance, under a DirectColor
24 visual (8/8/8), due to the way pixels index the color cells, you can have
only 256 tints of each primary per colormap, and these tints are the same for
all colors in your colormap. Note that your hardware might know more than 256
tints in each primary, but can only handle that ammount at the same time[1].
Given this, XAllocColor works by looking at each primary in turn: if
you've already allocated enough different colors so that you've exhausted the
red planes, all X can do is use an existing value. Otherwise, it can allocate
a new one. In all cases, that builds the corresponding bitfields in the pixel
value, and this not only affects the color you're allocating (as in
PseudoColor visuals) but also *all* subsequently allocated colors that share
the same value for the red mask part. You then repeat the process for the
other components.
Footnotes:
[1] that's also why many displays support several TrueColor visuals of the
same depth: they implement different gamma curves of stuff like that.
--
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
8066
days inactive
8071
days old
7 comments
6 participants
participants (6)
-
Adam Duck -
Didier Verna -
Glynn Clements -
Sean MacLennan -
Stephen J. Turnbull -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks