#153 Aterm transparent shading doesn't work.

Tim Garton

Summary basically says it all. If you open up a
transparent aterm that you want shaded, it doesn't
work. For instance:
aterm -tr -sh 50
gives you an aterm that is black. I assume this is in
the blackbox code and not the aterm code, since the
exact same aterm code works fine on blackbox 0.62x
Don't know how important you guys feel this is, but
just wanted to let you know.



  • Matthew Weier O'Phinney

    Logged In: YES

    What distribution are you using? What version of aterm? What
    are you using to set the root image? I'm on a debian
    (testing) box, using blackbox 0.65 and aterm 0.4.2, and have
    had succesful shaded transperency using "aterm -tr -sh 33"
    since sometime in the 0.62 series (and all during the 0.65
    alpha, beta, and rc series). I've used Esetroot, xloadimage,
    rox, and display to set the background image, and aterm has
    worked each time.

  • Nobody/Anonymous

    Logged In: NO

    btw, this does not happen on 61.1. I set the mailing list
    a message about this, but it was claimed that this was just
    an aterm bug. Same version of aterm, differnt version of
    blackbox = not working. Hmm. could this be a library issue?


  • Sean 'Shaleh' Perry

    • status: open --> closed-invalid
  • Sean 'Shaleh' Perry

    Logged In: YES

    Hopefully this will be the last time I have to explain how psuedo
    transparancy works.

    Applications which support transparency under X do it in one of two ways:

    a) the evil hack. They set their background to "parent relative" and since
    the parent of the window is the root window (aka desktop) the window
    gets root's background. The downside of this is if the root image changes
    the window does not get notified so a redraw does not automatically occur

    b) the Eterm method. This is the way most current applications handle
    transparency. The program which sets the root image also sets a "hint" on
    the root window which tells other programs what the root image is so that
    they too can use it. If the root image gets changed this hint is changed so
    everyone can stay on the same page.

    $ xprop -root |grep PMAP
    ESETROOT_PMAP_ID(PIXMAP): pixmap id # 0x1000003
    _XROOTPMAP_ID(PIXMAP): pixmap id # 0x1000003

    The key thing to note here is the window manager has *NOTHING* to do
    with the setting, reading or anything else of the root image or the two

    Now what changed is bsetroot now properly sets the two hints when it
    sets the background image. This will happen with most of the default
    blackbox styles via their rootCommand option. If you then set the root
    image to something else using a program which does not understand the
    new hinting convention (like say, xv) then aterm will still read the root hint
    which now points to a different image than what you see.

    So, how do you fix this? You can either a) edit your style's root command
    and use your program only or b) use a program which properly sets the
    hints like Esetroot or several others.

    I hope this explanation helps you and also others who see this problem.

    Since this bug is not actually a Blackbox (or any other Blackbox program)
    bug I am marking it invalid and closing it.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks