[xmonad] Transparent Border with Chrome Beta/Unstable

[Eyal Erez]

Hi,

I've recently update my machine to find that chrome's window border (orange
on all my other windows) is now transparent. I noticed that Google have
added their new Aura graphics stack instead of GTK+
<https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/Zpu9801pPRc>,
and I'm wondering if this is not playing nicely with xmonad. Downgrading
to Chrome stable solves the problem. But I'm guessing that once the stable
version gets updated, I'll get the same issue again.

Is anyone else seeing this? Is there anything I can do to confirm that
this is the problem or fix it somehow?

Thank you,

[Brandon Allbery]

Post by Eyal Erez
I've recently update my machine to find that chrome's window border
(orange on all my other windows) is now transparent. I noticed that Google
have added their new Aura graphics stack instead of GTK+
<https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/Zpu9801pPRc>,
and I'm wondering if this is not playing nicely with xmonad. Downgrading
to Chrome stable solves the problem. But I'm guessing that once the stable
version gets updated, I'll get the same issue again.
Is anyone else seeing this? Is there anything I can do to confirm that
this is the problem or fix it somehow?

One drawback of using server side borders is that the transparency behavior
is defined by the application, since the border is technically part of the
application window and not a frame window. It may be possible to specify
the border color as RGBA (e.g. focusedBorderColor = "#ffa500ff") instead of
RGB... but this may then break (i.e. cause BadMatch X11 errors) windows
which are *not* RGBA.

(The #xxx format for colors may not work for RGBA; it may need to be
"rgba:1/0.65/0/1".)

[Eyal Erez]

Chrome has finally upgraded and now the stable version is exhibiting the
same behavior. I've also noticed that evince (document reader) is also
showing a really ugly transparent gap around the edge. I've attached a
screenshot to illustrate the problem. The two chrome windows and evince
have the faulty transparent gap. However, other windows are not (e.g.
emacs and rxvt on the right).

Does anyone know how to fix this?

Post by Brandon Allbery

Post by Eyal Erez
I've recently update my machine to find that chrome's window border
(orange on all my other windows) is now transparent. I noticed that Google
have added their new Aura graphics stack instead of GTK+
<https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/Zpu9801pPRc>,
and I'm wondering if this is not playing nicely with xmonad. Downgrading
to Chrome stable solves the problem. But I'm guessing that once the stable
version gets updated, I'll get the same issue again.
Is anyone else seeing this? Is there anything I can do to confirm that
this is the problem or fix it somehow?

One drawback of using server side borders is that the transparency
behavior is defined by the application, since the border is technically
part of the application window and not a frame window. It may be possible
to specify the border color as RGBA (e.g. focusedBorderColor = "#ffa500ff")
instead of RGB... but this may then break (i.e. cause BadMatch X11 errors)
windows which are *not* RGBA.
(The #xxx format for colors may not work for RGBA; it may need to be
"rgba:1/0.65/0/1".)
--
brandon s allbery kf8nh sine nomine associates
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

[Brandon Allbery]

Post by Eyal Erez
Chrome has finally upgraded and now the stable version is exhibiting the
same behavior. I've also noticed that evince (document reader) is also
showing a really ugly transparent gap around the edge. I've attached a
screenshot to illustrate the problem. The two chrome windows and evince
have the faulty transparent gap. However, other windows are not (e.g.
emacs and rxvt on the right).
Does anyone know how to fix this?

This is really the same problem as
https://code.google.com/p/xmonad/issues/detail?id=581 and fixing it
requires modifying the core to understand RGBA windows and visuals, as I
said. There are no quick fixes.

[Eyal Erez]

Thanks for your reply.

Is anyone working to fix this by any chance?

Post by Brandon Allbery

Post by Eyal Erez
Chrome has finally upgraded and now the stable version is exhibiting the
same behavior. I've also noticed that evince (document reader) is also
showing a really ugly transparent gap around the edge. I've attached a
screenshot to illustrate the problem. The two chrome windows and evince
have the faulty transparent gap. However, other windows are not (e.g.
emacs and rxvt on the right).
Does anyone know how to fix this?

This is really the same problem as
https://code.google.com/p/xmonad/issues/detail?id=581 and fixing it
requires modifying the core to understand RGBA windows and visuals, as I
said. There are no quick fixes.
--
brandon s allbery kf8nh sine nomine associates
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

[Brandon Allbery]

Post by Eyal Erez
Thanks for your reply.
Is anyone working to fix this by any chance?

Not so far as I am aware. I'd noticed the shortcoming some time ago but
nothing came of it.

[Eyal Erez]

Is it just me or has the liveliness on the xmonad project really calmed
down in the last few months?
I'm noticing a lot less activity in the forums than it used to be.

Post by Brandon Allbery

Post by Eyal Erez
Thanks for your reply.
Is anyone working to fix this by any chance?

Not so far as I am aware. I'd noticed the shortcoming some time ago but
nothing came of it.
--
brandon s allbery kf8nh sine nomine associates
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

[Brandon Allbery]

Post by Eyal Erez
Is it just me or has the liveliness on the xmonad project really calmed
down in the last few months?
I'm noticing a lot less activity in the forums than it used to be.

I can't speak for the other folks involved with xmonad, but I've been
fighting some kind of viral ick for almost a month now that has severely
limited my ability to do much of anything beyond replying to email. :(

There's still a fair amount of activity in the #xmonad channel on Freenode,
though.

[Zev Weiss]

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:

.window-frame, .window-frame:backdrop {
box-shadow: 0 0 0 black;
border-style: none;
margin: 0;
border-radius: 0;
}

.titlebar {
border-radius: 0;
}

(Can't claim credit for that myself, found it via a google search some months ago and no longer remember where or what the relevant search terms were.) Maybe hackishly useful in lieu of a "real" fix though?


Zev

Chrome has finally upgraded and now the stable version is exhibiting the same behavior. I've also noticed that evince (document reader) is also showing a really ugly transparent gap around the edge. I've attached a screenshot to illustrate the problem. The two chrome windows and evince have the faulty transparent gap. However, other windows are not (e.g. emacs and rxvt on the right).
Does anyone know how to fix this?
I've recently update my machine to find that chrome's window border (orange on all my other windows) is now transparent. I noticed that Google have added their new Aura graphics stack instead of GTK+, and I'm wondering if this is not playing nicely with xmonad. Downgrading to Chrome stable solves the problem. But I'm guessing that once the stable version gets updated, I'll get the same issue again.
Is anyone else seeing this? Is there anything I can do to confirm that this is the problem or fix it somehow?
One drawback of using server side borders is that the transparency behavior is defined by the application, since the border is technically part of the application window and not a frame window. It may be possible to specify the border color as RGBA (e.g. focusedBorderColor = "#ffa500ff") instead of RGB... but this may then break (i.e. cause BadMatch X11 errors) windows which are *not* RGBA.
(The #xxx format for colors may not work for RGBA; it may need to be "rgba:1/0.65/0/1".)
--
brandon s allbery kf8nh sine nomine associates
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
--
There are 10 types of people, those who know binary and those who don't.
<2014-12-06-173823_3440x1440_scrot.png>_______________________________________________
xmonad mailing list
http://www.haskell.org/mailman/listinfo/xmonad

[Eyal Erez]

@Brandon: Feel better.

@Zev: The gtk css didn't work for me, but zathura looks interesting (I've
been using qpdfview).

Well, I guess it's time to switch to Firefox until this blows over.

Post by Zev Weiss
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
.window-frame, .window-frame:backdrop {
box-shadow: 0 0 0 black;
border-style: none;
margin: 0;
border-radius: 0;
}
.titlebar {
border-radius: 0;
}
(Can't claim credit for that myself, found it via a google search some
months ago and no longer remember where or what the relevant search terms
were.) Maybe hackishly useful in lieu of a "real" fix though?
Zev

Post by Eyal Erez
Chrome has finally upgraded and now the stable version is exhibiting the

same behavior. I've also noticed that evince (document reader) is also
showing a really ugly transparent gap around the edge. I've attached a
screenshot to illustrate the problem. The two chrome windows and evince
have the faulty transparent gap. However, other windows are not (e.g.
emacs and rxvt on the right).

Post by Eyal Erez
Does anyone know how to fix this?
I've recently update my machine to find that chrome's window border

(orange on all my other windows) is now transparent. I noticed that Google
have added their new Aura graphics stack instead of GTK+, and I'm wondering
if this is not playing nicely with xmonad. Downgrading to Chrome stable
solves the problem. But I'm guessing that once the stable version gets
updated, I'll get the same issue again.

Post by Eyal Erez
Is anyone else seeing this? Is there anything I can do to confirm that

this is the problem or fix it somehow?

Post by Eyal Erez
One drawback of using server side borders is that the transparency

behavior is defined by the application, since the border is technically
part of the application window and not a frame window. It may be possible
to specify the border color as RGBA (e.g. focusedBorderColor = "#ffa500ff")
instead of RGB... but this may then break (i.e. cause BadMatch X11 errors)
windows which are *not* RGBA.

Post by Eyal Erez
(The #xxx format for colors may not work for RGBA; it may need to be

"rgba:1/0.65/0/1".)

Post by Eyal Erez
--
brandon s allbery kf8nh sine nomine

associates

Post by Eyal Erez
unix, openafs, kerberos, infrastructure, xmonad

http://sinenomine.net

Post by Eyal Erez
--
There are 10 types of people, those who know binary and those who don't.

<2014-12-06-173823_3440x1440_scrot.png>_______________________________________________

Post by Eyal Erez
xmonad mailing list
http://www.haskell.org/mailman/listinfo/xmonad

[Brandon Allbery]

Post by Zev Weiss
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

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.

[Eyal Erez]

This is finally fixed.

I noticed a new (I think) option on the Chrome settings called "Use system
title bar and borders".
Checking this makes xmonad window borders work correctly again.

Post by Brandon Allbery

Post by Zev Weiss
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

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
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

[Brandon Allbery]

Post by Eyal Erez
I noticed a new (I think) option on the Chrome settings called "Use system
title bar and borders".
Checking this makes xmonad window borders work correctly again.

That has been there for a couple of years.

[Eyal Erez]

:( must've missed it.

Post by Brandon Allbery

Post by Eyal Erez
I noticed a new (I think) option on the Chrome settings called "Use
system title bar and borders".
Checking this makes xmonad window borders work correctly again.

That has been there for a couple of years.
--
brandon s allbery kf8nh sine nomine associates
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net