[wmii] Re: (pseudo-)transparency bug in rxvt-unicode >= 5.x

On Fri, May 19, 2006 at 12:20:19PM +0200, "Anselm R. Garbe" <garbeam_AT_wmii.de> wrote:
> Hi there,

First of all:

> Just for documentation, I give no shit about it anymore,
> because it seems that my mail has been defered by the developer
> of rxvt-unicode.

Your mail has been sent out by your mail server at "Fri, 19 May 2006
13:03:34 +0200". It was sent to subscribers around "Fri, 19 May 2006
13:09:36 +0200" (at least thats when I got my copy, the web archive itself
as updated 6 minutes earlier).

Neither was it deferred, nor moderated nor anything else short of a timely
delivery happened...

The above claim (lie?) is symptomatic for your behaviour. I would have
ignored it if you wouldn't have dragged it into public yourself :/

> However I'm subscribed.

If you weren't, the mail would have been defered for moderation indeed. It
usually takes a day until it gets forwarded, but in your case, no such thing
happened, nor took it more than a few minutes to forward your mail to
subscribers.

> I joined the IRC channel to report schmorp about a bug in rxvt-unicode,
> yesterday. Because he didn't seemed (http://wmii.de/urxvt.bug) to be
> interested in it, I send this report to this list. I digged into the

Well, at least you did your homework in the meantime. In IRC, you insisted
on xlib sending expose events to other applications and other very
confusing (actually wrong :) notions about X11. Since you didn't answer my
questions about the actual symptoms, I indeed wasn't much interested in
your "report", as there simply wasn't any.

> rxvt-unicode code on my own, and found a semi-solution, which fixes the
> bug for me, but not in general, because the overall behavior of
> transparency-related refreshes in rxvt-unicode is quite broken.

Thats a bold, and untrue, statement that you cannot back-up (mostly
because you prove that you don't know the transparency code of urxvt in
your own mail).

> If rxvt-unicode is run with -tr (Opt_transparent) argument, then it
> performs XClearWindow calls on its parent windows, which rxvt-unicode
> does not own(!) at all.

In some cases, yes, this is what happens and what _has_ to happen for it
to work. It doesn't happen with your wm... Tough! It works with much more
common window managers out there, though. Your hack would probably make it
work with your wm and would break others.

In any case, if that mode of transparency doesn't work with your wm, you
are free to use another that will work. The world isn't perfect, and that
particular way of implementing pseudo-transparency cnanot work everywhere.

Reading the documentation or even the FAQ would have helped a long way, of
course...

> Besides this, a side-effect (which is quite a hack indeed) is used in

This kind of pseudo-transaprency is indeed a hack, and indeed is not in
compliance to the ICCCM. Neither is your proposed solution, of course,
which, as I mantioned, just breaks other WMs.

Thats the reason why rxvt-unicode implements correct transparency, too,
and pixmap-pseudo-transparency, too.

Neither of those has the problems you claim they have.

The really bad thing is that I told you about that in IRC, but you didn't
listen :(

> To fix the overall transparency behavior, I make following proposals as
> starting point:

That is indeed a starting point. Fortunately, rxvt-unicode does not rely
on the hackish and slightly broken algorithm you propose, but uses a more
correct one (for example, it doesn't flash the screen as aterm does, nor
does it fail to work with modern desktop-background-setting programs).

> - If you need (pseudo-)transparency, check if XROOTPMAP_ID is set as

grep'ing through the rxvt-unicode sourcecode for XROOTPMAP_ID might be
enlightening. Instead of "proposing" what rxvt-unicode already does, how
about proposing improvements instead?

> Thus you don't need to clear any windows you don't own, you only need to
> take care of your own vt window, and of the root window if you need to
> fetch the XROOTPMAP_ID.

It's just a matter of configuration and taste. For example, raeding the FAQ
for rxvt-unicode explains all this. But, as I had to find out, reading
documentation and dealing with facts are not your strong points.

Either way, what you describe is just as broken (and not specified by the
ICCCM either). There is a correct way: using a composite manager, which
is well-supported by urxvt, probably better than by any other terminal
emulator out there.

There are currently four ways to get transparency with urxvt-unicode:

1. pseudo transparency using pixmap inheriting.
   * it's a hack, and will ever be a hack.
     (it is also what your patch breaks with many wm's)
2. pseudo transparency by re-using the background pixmap
   * same configuration, works whenever a freedesktop-"compliant"
     background setting program is used.
3. pseudo transparency, using a prespecified pixmap
   * implemented by the "automove-background" extension
4. real transparency
   * must be specified by giving the background (or other colours)
     an alpha component. very clean solution, and correct, too.

Only the first will not work with your window manager (unless it's very
buggy), the remaining three _do_ work.

In any case, I don't know why you hate rxvt-unicode so much that you have
to spread lies about it publicly. Obviously, you didn't try to read either
the source nor the documentation before making your claims (which is
exactly the same behaviour as in IRC, where you made me grep through xlib
sources to find out that you were telling the untruth... "just believe
me".. yeah.. thanks for wasting my time).

I am not amused, however. This is not a harmless prank by somebody who
doesn't know better: You wasted quite a bit of my time by making lots of
claims that are untrue or turned out to be untrue (this is refered to as
"trolling"). All that was easily verifiable, but it still took time to do
so. You are sabotaging free software development that way, as that time
could have been used in a much more productive way, such as fixing actual
bugs by other users.

Your behaviour is _not_ acceptable :(

-- 
                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __      pcg_AT_goof.com
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE