Re: issues for future version

[Sasha_Vasko osca state mo us]

> Sasha_Vasko osca state mo us wrote:
> > - Window Layers. AS was discussed some time ago, there is a distinctive
need
> >   to provide for window layering. For example you can place all your
> >   panels/docks/wharfs in the higher layer, to keep them always visible,
or
> >   move terms onto the bottommost layer to keep them from obscuring
other
> >   windows. It was proposed as KEEP_ON_TOP hint, before, but IMHO layers
> >   are much cleaner and flexible way to do that.
>
> I thought layers were rejected in favour of semantic hints? (The
> rationale was that stays-on-top & friends should be configured through
> the window manager, not client-by-client.)

Yes, IMHO window manager configuration is all that is needed here, but
since
there was such a strong demand for something along KEEP_ON_TOP lines, I
would
agree to yeld a little bit, and add hints. But not dictating hints, like

TOPMOST_LAYER or BOTTOMMOST_LAYER, but instead something like
KEEP_HIGH_PROFILE/KEEP_LOW_PROFILE.

Again I'm not a strong supporter of that stuff, just merely trying to
accomodate other's opinions, so I won't fight for that feature.

> Of course the WM can still implement layers, but why should clients know
> about them?
>
> > - Pseudo-Transparency support (aka Root pixmap ID).
>
> Could this be implemented using parent-relative backgrounds for the
> client window and the frame window? The WM would set a hint on the root
> window to indicate support for this kind of pseudo-transparency. It
> would work nicely with virtual roots - the virtual root would be the
> parent of the frame window, so its background would be visible rather
> than the background of the (possibly obscured) root window. How would
> the root pixmap ID work with virtual roots?

Problem is that pure transparency as provided by ParentRelative is not
usefull. In most of the cases you would want to shade or tint root
background,
to make text/graphics on top of it more readable.

The only way to do that with ParentRelative is to use Function feature of
GC,
and fill area with some color using function = Xand. For decent effect it
limits you to only 6 pure colors, where you simply filter out one or two
color channels. That is a technique I used in aterm and it works rather
well.

But that does not allow you to do shading and more fine-tuned tinting,
which
is desireable for quite a few cases ( at least 50%). To do true
tinting/shading
you have to obtain actuall pixmap/XImage of the area of root background
( Unless you use new X Render extensions, of course). There are two ways of
doing that - you can either create override_redirect window with
ParentRelative
background over the interesting portion of the root, map it on top, wait
for
Expose, and XCopyArea from it. Another way is to keep a copy of root
Pixmap,
and broadcast ID of that pixmap. That has disadvantage of duplicating the
memory,
which could be several megs of wasted memory.

That latter approach is what is used by E and Eterm, and I subsequently
adopted
it in aterm and AfterStep. AFAIK it is also used by other window managers,
so
you may consider it to be de-facto standard. Problem is that some root
background applications, does ot adopt it resulting in frustration from
user.
Idea is that if this is made into "official" standard - it would get
adopted
by these other programs.

Of course I would prefer different approach and instead of having copy of
the
root background laying around - have the program that sets root background,
serve as the rendering process, providing needing applications with desired
pieces of the root background on request, perhaps event shaded/tinted and
ready for use. The rationale behind this is that such a program is likely
to
have client-side copy of the image, and can perform shading/tinting/tiling
without additional expense of transfering image from the server. That would
allow implementing transparent apps with next to nothing effort and no
duplicating of tinting/shading code ( wich is rather complex code BTW ).
That would be extremly usefull for things like KDE/GNOME where, if used in
several apps at a time, it could save tremendouse amounts of
memory/performance.

Of course objection here is that wenow have wonderfull X Render extension
that could do all of the above even utilizing hardware acceleration.
Problem here is that it will take several years to become sufficiently
portable, and make it into other X Servers out there, where as above
proposed renderer could be implemented overnight, be very portable, and
cleanup huge amounts of existing code. Localizing transparency rendering
in the single process, has another advantage of added abstruction.
Such process could be using XRender where possible, and some custom code
where not possible, and all that would be done transparently for other
apps. It is common sense idea, and that's similar to what is behind
raster's Evas and what I'm doing presently with libAfterImage and
AfterStep.

Some ppl may object that this is not exactly Window Management topic,
but it boils down to the fact that it is exactly Window Manager who is
maintaining root backgrounds (for multiple desktops possibly), and I
would anticipate one form or another of the bove implemented by different
window managers anyways. By making it standard, we could make it much
easier on apps developers, and improve compatibility.



>
> Michael

Sasha