You are not logged in.
After I reinstalled Arch and downloaded all my previous configs and dot-files, everything started to look just fine except for one thing: xterm is not becoming translucent as per the picom.conf.
Interestingly, all the other terminal emulators do. For instance, urxvt works just fine, but I like xterm more, hence the cry of help.
I guess, there is some default xterm config or dot-file that overrides picom config, but I couldn't find any.
What could be the issue?
Last edited by Stonegrip (2023-08-26 23:21:34)
Offline
Has picom been started? Either manually at Command line or in some Autostart file?
_________________________
Asus X200CA Notebook
Offline
I assume you installed transset-df from AUR and modified your .bashrc file per the xterm wiki.
If all of that is set up, then I'm out of ideas.
_________________________
Asus X200CA Notebook
Offline
xterm is not becoming translucent as per the picom.conf.
Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
What rule does not apply (picom.conf) against what window (xterm xprop)?
I guess, there is some default xterm config or dot-file that overrides picom config, but I couldn't find any.
Offline
And the prize goes to Mneiner ![]()
no, seriously. Thanks a ton for referring me to the Xterm page on ArchWiki. I thought I knew all that, and there's no point even reading it. However, once I read its Section 5.1 on transparency, I got to know that the only way to make Xterm transparent is with transset-df, which I was not aware of.
So I installed transset-df and xcompmgr, added the following to .bashrc:
xcompmgr &
[ -n "$XTERM_VERSION" ] && transset-df --id "$WINDOWID" >/dev/null
and here comes transparency.
Appreciate all the help. I must have forgot all about it since I created my picom config.
The thread is closed.
Offline
the only way to make Xterm transparent is with transset-df
No it's not?
transset* set a property on the window (_NET_WM_WINDOW_OPACITY) which is interpreted by compositors, there're several ways (incl. just xprop) to set that, but more importantly, picom supports per window rules for their behavior.
So are you now running picom or xcompmgr?
It cannot be both and it frankly sounds as if you had not run *any* compositor before?
Offline
Hi Seth,
so, here is what my thinking process was before: I thought that if I download and enable picom via i3 config with the following piece of code:
exec --no-startup-id picom --config ~/.config/picom/picom.confthat would suffice to execute picom's config, which is as follows:
inactive-opacity = 0.90;
active-opacity = 0.95;
frame-opacity = 0.80;
inactive-opacity-override = false;
#blur: {
# method = "dual_kawase";
# strength = 9;
# background = false;
# background-frame = false;
# background-fixed = false;
#};
shadow=true;
shadow-radius: 7;
shadow-exclude = [
"class_g = 'conky'"
];
fade-exclude = [
"class_g = 'conky'"
];
opacity-rule = [
"100:class_g = 'firefox'",
"100:class_g = 'conky'"
];
blur-background-exclude = [
"window_type = 'dock'",
"window_type = 'desktop'",
"class_g = 'firefox'",
"class_g = 'conky'"
];And it did work with URXVT terminal emulator, but did not fly for Xterm.
After Mneiner suggested RTFM (AKA xterm archwiki), I spotted the following statement there, namely:
Section 5.1 Automatic Transperancy:
... Now, each time you launch a shell in an xterm and a composite manager is running, the xterm window will be transparent. ... Note that your terminal will not be transparent if you launch a program other than a shell this way. It is probably possible to work around this if you want the functionality.
so, as I described in my previous post, I started launching xcompmgr at the background every time I launch Xterm by adding the "xcompmgr &" code to .bashrc and then I apply transset-df by adding the "[ -n "$XTERM_VERSION" ] && transset-df --id "$WINDOWID" >/dev/null" line to the bashrc file. And it works fine. I obviously tested these steps manually before adding them to the bashrc file.
It is hard for me to answer your question
So are you now running picom or xcompmgr?
as I think I am using both: Picom is run from the i3 config and xcompmgr is launched through .bashrc. Could you please elaborate on what steps in the aforementioned process are redundant or wrong?
Thanks a ton in advance.
Last edited by Stonegrip (2023-08-28 15:39:16)
Offline
Please use [code][/code] tags, not "quote" tags. Edit your post in this regard.
as I think I am using both
That's not possible.
ps aux | grep -E 'picom|xcomp'picom will however respond to _NET_WM_WINDOW_OPACITY just as much as xcompmgr would
If that (or _NET_WM_OPACITY) is set for the specific (xterm) window, you'll however need to enforce your local config w/ "inactive-opacity-override = true;" (which seems to be the only relevant opacity setting)
Offline
Seth,
you are right. I've checked with ps aux, and it appeared that Picom is not amongst the active processes, only xcomp is running.
Now I think I started realizing what has happened, and what made me think Picom was activated:
My Conky has it's own config, and hence it worked just fine before the xcomp was installed.
And Urxvt became transparent as a result of the following line from the .Xresources file:
URxvt.transparent: trueNot realizing that, I thought it all happened as a result of using Picom.
So how should Picom be activated then?
Offline
conky and urxvt provide what's called "fake transparency" where they just use the root pixmap as their own window pixmap (and paint on top of that)
You can run picom from your i3 config or session scripts (xinitrc?) - you bashrc is a really bad place to run any of this.
First try whether you can interactively run "picom --config ~/.config/picom/picom.conf" (you'll have to kill xcompgr first, you cannot run to compositors at the same time) and if that works, probably post your i3 config, as that seems not to do what you expect it to do.
Offline