> >> Atom's hold integer indexes into the X server. You store the Pixmap ID and >> then ask for it. > > So of: > > _XSETROOT_ID > _XROOTPMAP_ID > ESETROOT_PMAP_ID > > Which is the one that you're supposed to use? I assume that > ESETROOT_PMAP_ID is the non-standard one that Eterm is looking for. >
I will have to read the Eterm code, I think this represents various versions of various tools. >> The id is however standard among GNOME, E, other wms, and I think even good >> parts of KDE. > > Hm... why would the window manager care at all? It's not responsible for > what happens inside the window frame, is it? I thought the application > was. Of course, if the window manager itself is creating the window, then > it IS the application. ^_^ > sorry, my meaning was that wmaker's tool to set backgrounds, the KDE set, etc. >> sorta. You say "draw my background as if I were my parent". You get no >> control or access. > > I've noticed that if I set the background with Esetroot, then it takes > longer for aterm to do things that involve resizing the window, like > maximization. Is that because aterm has to retrieve the bitmap, then > cookie-cutter out the appropriate piece, then set the background of the > window itself? When I maximize, it tiles its piece of the background (that > the old window had) multiple times over the window, then it blinks, then it > paints it again correctly. > > I assume that using parent-relative is faster, because then the X server > handles it? I don't see the blink in that case. > > Seems like it would also increase memory usage on the part of the > application, if it had to maintain a local copy of the bitmap somewhere. > part of this is the code in aterm. Eterm is no where near as slow in that respect. >> > >> I have not tried display recently, it may have been updated. > > Well, I just tried display and wmsetbg. I currently have bsetbg configured > to use > Esetroot, and aterm does not pick up the root window change. It's still > using the one my style set, meaning that the atom is still pointing at the > bitmap that Esetroot used? So I'd assume that display is one with a > problem? > > OTOH, wmsetbg apparently does "the right thing", because aterm picked up > right away that the root had changed. Perhaps blackbox should "adopt" > wmsetbg. ^_^ > will look into this further.