Re: New feature proposal & transparent aterm

Sasha_Vasko@osca.state.mo.us
Mon, 22 Mar 1999 09:20:20 -0600





Geof Wing wrote :

>Doug Alcorn <alcornd@earthlink.net> typed about "Re: New feature proposal"
>:Andre Oliveira da Costa <costa@tecgraf.puc-rio.br> writes:
>:> can't remember how far it went, but here's my proposal: what if we
could
>:> change the foreground color on unfocused aterms? This way we could set
>:> it to a darker color, for example, to keep unfocused windows from
>:> getting as much attention as the focused one.
>:This would be cool.  However, it would be tricky interaction between
>:the WM and aterm.  I don't think the term itself (correct me, Ethan or

>Sure it does, it gets a FocusOut event, sent by the WM.

That's true, I'm gonna try to implement it and see what will happen.

>And typed about "Re: transparent aterm"
>:Enzo Marinari <marina@chimera.roma1.infn.it> writes:
>:> I compiled aterm 3.4 on Digital Unix. It compiled fine after
>:> standard ./configure, with no problems. When I start it (not under
>:> Afterstep, but under the standard Digital Unix WM) as soon as I move it
on
>:> the screen it crashes with a silent Segmentation fault core dump. This
>:> happens both if I start it with -tr and if I do not (but I understand
this
>:> is the default, so no surprise here).
>:All of the pseudo-trans terms require that the root window background
>:setting program define a property in X.  The Enlightenment WM started

I would like to disagree with Geoff here :)

>No, the only purpose of the Xatom is to tell the term that the background
>has _changed_.  You have to consider the whole method of how transparency

It is also used as the root background pixmap ID, and in the case when it's
available
aterm does not need to go up to root window and do any "wierd things" - it
just uses this ID
to set it's own background  accordingly.

>is achieved.  The term goes out and finds it parent window (and its
>parent, etc.).  Then it does something evil.  It changes properties of
>windows that it didn't create and has no business messing with.  However,
>rather than continually trying to find out x many times per second whether
>the pixmap of the root window has modified, it relies on the parent (WM)
>to announce via an Xatom.  Of course, since it's fiddled with other
program's
>windows, the term has to cope with the other program doing whatever it

The only property it changes is a background Pixmap - which is pretty safe,
except
that it can override any graphics displayed by window Manager to decorate
window's
frame.

>wants with those windows - and at the moment only handles the most likely
>occurences.

But by no means that can cause aterm's segmentation fault - the problem is
somewhere
else. I don't have Digital Unix at hand to debug it - so if anybody out
there is capable of
debugging and has Digital Unix - please find out where the problem is and
let me know.
I would appreciate it very much.

>Geoff Wing   <gcw@pobox.com>

Sasha



--
   WWW:   http://www.afterstep.org/
   FTP:   ftp://ftp.afterstep.org/
   MAIL:  http://www.caldera.com/linuxcenter/forums/afterstep.html