] >Date Index
Re: [wmx] Frame focus strangeness with transparent windowscannam
- Fri Jul 07 10:40:25 2000
Jo Moskalewski <firstname.lastname@example.org> writes:
> Aterm is based on rxvt, so I can tell you it's the same
> with rxvt
I'm not sure I understand you correctly here, but rxvt is a
pretty common program that I haven't noticed any problems with
in any of various versions for several years.
That said, the problem with aterm (which I have never used) is
an interesting one. It's not apparent to me what causes it.
The structure of windows is something like this: The client
window (the application itself) is reparented when wmx or the
client starts, to become a child of the m_parent that you see in
Border.C. The tab (that part of the border that remains visible
regardless of focus) is another child of the same parent, as are
the iconify button and the resize handle. (This caused serious
problems with early GTK apps which would sometimes drop dead on
discovering that their main window was not, as expected, their
parents' only child. I'm sure there's a real-world metaphor
there somewhere. There always is.) But the part of the border
that indicates focus is not a child window, it is actually the
parent window itself which is reshaped dynamically as focus
changes -- an incredibly inefficient operation. And this is the
bit whose background is being messed with by aterm -- which makes
no sense to me, in that surely most window managers reparent the
client window with a parent on which the frame is drawn.
Presumably the answer lies in the aterm source somewhere.