Just annotations of little "how to's", so I know I can find how to do something I've already done when I need to do it again, in case I don't remember anymore, which is not unlikely. Hopefully they can be useful to others, but I can't guarantee that it will work, or that it won't even make things worse.
Fix Google Chrome's ugly thick transparent-but-shadowed borders on compositors such as picom
Tags bug/feature, chrome, compton, openbox, picom
By adding this on the "shadow exclude" section:
Source:
https://github.com/chjj/compton/issu...mment-45407446
They've decided to once again reinvent the same GUI in the latest version of Chrome, but with some added dysfunctionalities or incompatibilities with more or less standard compositor configurations. Its context menus all of a sudden had a rather thick transparent border, only visible because there was also the default compositor's shadow, which isn't normally expecting to deal with sub-windows with thick transparent borders.
Firefox used to have a similar issue, with comparably thinner transparent-but-shadowed borders, at some point in time. It may have been even 10 years ago, as this source is from 2014. I think that I had maybe fixed with some css modification on FF itself, or maybe I just ignored while it existed, it as it was not as disturbing as Chrome's. In any case, I'd guess this config would prevent the problem from happening in either browser and maybe more cases. If it results in any problem elsewhere, the rule can be made specific to some applications, with something along the lines of « wm_class="google-chrome" && » preceding the config statement.
While I didn't recall this kind of problem in Firefox recently (maybe partly because I barely have used it over the past few years), apparently it is still there, although in the reduced form/size, much thinner and only in some menus, not everywhere, like Chrome. I only noticed after I came up with a version of the rule that would negate firefox specifically, since Chrome's drop-down menus's properties provided by xprop don't textually attribute it to Chrome itself. The only "link" to Chrome is its icon, which we can't use as a rule in picom, AFAIK.
By the way, in order to get the xprop output from a dropdown menu, you issue xprop in some terminal, "alt+tab" to the window you want to get the submenu, and then use the "menu" key on the keyboard, and click that with the mouse. That was the only way I managed to get the xprop output from the context menu on Chrome.
Code:
"argb && (override_redirect || wmwin)"
https://github.com/chjj/compton/issu...mment-45407446
They've decided to once again reinvent the same GUI in the latest version of Chrome, but with some added dysfunctionalities or incompatibilities with more or less standard compositor configurations. Its context menus all of a sudden had a rather thick transparent border, only visible because there was also the default compositor's shadow, which isn't normally expecting to deal with sub-windows with thick transparent borders.
Firefox used to have a similar issue, with comparably thinner transparent-but-shadowed borders, at some point in time. It may have been even 10 years ago, as this source is from 2014. I think that I had maybe fixed with some css modification on FF itself, or maybe I just ignored while it existed, it as it was not as disturbing as Chrome's. In any case, I'd guess this config would prevent the problem from happening in either browser and maybe more cases. If it results in any problem elsewhere, the rule can be made specific to some applications, with something along the lines of « wm_class="google-chrome" && » preceding the config statement.
While I didn't recall this kind of problem in Firefox recently (maybe partly because I barely have used it over the past few years), apparently it is still there, although in the reduced form/size, much thinner and only in some menus, not everywhere, like Chrome. I only noticed after I came up with a version of the rule that would negate firefox specifically, since Chrome's drop-down menus's properties provided by xprop don't textually attribute it to Chrome itself. The only "link" to Chrome is its icon, which we can't use as a rule in picom, AFAIK.
By the way, in order to get the xprop output from a dropdown menu, you issue xprop in some terminal, "alt+tab" to the window you want to get the submenu, and then use the "menu" key on the keyboard, and click that with the mouse. That was the only way I managed to get the xprop output from the context menu on Chrome.
Total Comments 0
