Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  XInternAtom
Message-ID: <9104161855.AA03179@lightning.McRCIM.McGill.EDU>
Date: 16 Apr 91 18:55:05 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 34

> I have run in to what looks like an X server bug.  I create an atom
> on the root window (through an application), delete it using xprop
> and confirm that it is gone (using xprop).

Atoms are not attached to windows.  Atoms are just names; the things
that xprop manipulate are properties.  Properties are named by atoms.
(Atoms are purely a performance optimization.  The protocol could have
been designed to pass strings back and forth instead of Atoms, but it
would have made things less efficient, and the designers apparently
felt the difference was significant.[%])  I would guess you are
creating an atom, then putting a property named by that atom on the
root, then using xprop to delete it and check that it's gone.

[%] Not that I think they're wrong; I simply do not have any data to
    tell, since I've never tried any experiments.

> When I re-run the application it thinks the property is still there.

> The call to XInternAtom(display, PROP_NAME, True) returns the value
> of the previous instance of the atom instead of None.

Well yes.  The Atom cannot be destroyed by anything short of a server
shutdown or reset.  The *property* probably is gone; use
XGetWindowProperty() to check for that from your application.

It is never reasonable to expect that any given Atom not exist.  Any
other application may have created an Atom by that name previously.
(In fact, I don't really see much point in having the third argument to
XInternAtom....)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu