[prev in list] [next in list] [prev in thread] [next in thread]
List: xmonad
Subject: Re: [xmonad] Transparent Border with Chrome Beta/Unstable
From: Brandon Allbery <allbery.b () gmail ! com>
Date: 2014-12-08 1:05:40
Message-ID: CAKFCL4UzM2OSpD87QV2J+gLnWumJxF4m7e16oMMVV9fAA5SprQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sat, Dec 6, 2014 at 11:06 PM, Zev Weiss <zev@bewilderbeest.net> wrote:
> I can't say with certainty if Chrome's unsightly-transparent-border
> problem is due to this, but at least for evince (which I've actually since
> stopped using in favor of zathura, for what it's worth) I was able to work
> around the problem by putting the following in ~/.config/gtk-3.0/gtk.css:
>
That wouldn't prevent xmonad's border from becoming translucent in an RGBA
visual, just avoid interactions with gtk3's own transparent decorations.
xmonad doesn't even try to handle RGBA visuals currently, or indeed
anything other than the server default visual (which is RGB), and I am not
surprised that it sometimes behaves badly. (How badly probably depends on
whether the window background is has an alpha other than 1.)
FIxing this: there are some potential questions that we would need to think
about. For example: while xorg no longer supports PseudoColor visuals
[thankfully; that'd be a real nightmare], it does offer some DirectColor
visuals. Do we want to deal with DirectColor, which will require an
entirely different set of operations to configure borders, since the pixels
in DirectColor are predefined and we must use lookups of closest existing
predefined colors instead of color allocation as with TrueColor? We'll need
to store border color information with windows, computing the pixels to use
based on the window visual and depth and presence of alpha channel, and the
current colormap entries we keep in the XConfig will serve no purpose since
they are only correct and safe to use with the default visual.
A side question might be whether to allow specification of the alpha for
the border. We'd presumably allow it to be specified and then mask it out
for visuals lacking an alpha channel.
--
brandon s allbery kf8nh sine nomine associates
allbery.b@gmail.com ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Dec 6, 2014 \
at 11:06 PM, Zev Weiss <span dir="ltr"><<a href="mailto:zev@bewilderbeest.net" \
target="_blank">zev@bewilderbeest.net</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">I can't say with certainty if Chrome's \
unsightly-transparent-border problem is due to this, but at least for evince (which \
I've actually since stopped using in favor of zathura, for what it's worth) I \
was able to work around the problem by putting the following in \
~/.config/gtk-3.0/gtk.css:<br></blockquote><div><br></div><div>That wouldn't \
prevent xmonad's border from becoming translucent in an RGBA visual, just avoid \
interactions with gtk3's own transparent decorations. xmonad doesn't even try \
to handle RGBA visuals currently, or indeed anything other than the server default \
visual (which is RGB), and I am not surprised that it sometimes behaves badly. (How \
badly probably depends on whether the window background is has an alpha other than \
1.)</div><div><br></div><div>FIxing this: there are some potential questions that we \
would need to think about. For example: while xorg no longer supports PseudoColor \
visuals [thankfully; that'd be a real nightmare], it does offer some DirectColor \
visuals. Do we want to deal with DirectColor, which will require an entirely \
different set of operations to configure borders, since the pixels in DirectColor are \
predefined and we must use lookups of closest existing predefined colors instead of \
color allocation as with TrueColor? We'll need to store border color information \
with windows, computing the pixels to use based on the window visual and depth and \
presence of alpha channel, and the current colormap entries we keep in the XConfig \
will serve no purpose since they are only correct and safe to use with the default \
visual.</div><div><br></div><div>A side question might be whether to allow \
specification of the alpha for the border. We'd presumably allow it to be \
specified and then mask it out for visuals lacking an alpha \
channel.</div><div><br></div></div>-- <br><div class="gmail_signature"><div \
dir="ltr"><div>brandon s allbery kf8nh \
sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" \
target="_blank">allbery.b@gmail.com</a> \
<a href="mailto:ballbery@sinenomine.net" \
target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, \
infrastructure, xmonad <a href="http://sinenomine.net" \
target="_blank">http://sinenomine.net</a></div></div></div> </div></div>
_______________________________________________
xmonad mailing list
xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic