My vote is against adopting wmsetbg. I tried to use it with aterm using
transparecy and shading. Every time I moved or resized the window it took
literally two seconds before it fixes the "transparency." It doesn't work well
with aterm if you have transparency and shading. It worked instantly with Eterm
but Eterm gives me lot's of other problems.
Eric Carlsen
[EMAIL PROTECTED]
---------- Forwarded message ----------
Date: Sun, 13 Jan 2002 13:51:05 -0800
From: Marc Wilson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Eterm transparency with blackbox?
On Sun, Jan 13, 2002 at 12:05:54PM -0800, Sean 'Shaleh' Perry wrote:
> You can ask for the root, but you are then responsible for many other things,
> the code is not as happy.
That makes sense. Must have happy code. ^_^
> 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.
> Eterm is non standard, the programs that do not support the ROOT_ID atom are
> all programs written before 1996. Some of them even worked under X11R5 (-:
>
> The standards were written before many of us began using X and have not changed.
>
> 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. ^_^
> 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.
> >> The proper solution is for bsetroot to properly set the Atoms that the
> >> transparent apps want.
> >
> > What about bitmaps in general? We have bsetbg, which requires one of
> > display/Esetroot/xsri/xv, and it sounds like only Esetroot does things in
> > the right way.
> >
> 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. ^_^
--
Marc Wilson
[EMAIL PROTECTED]
[EMAIL PROTECTED]
