Bug 1297349

Devilspie uses EWMH properties to control appearance of windows on X11, like  _NET_WM_WINDOW_OPACITY for opacity, but that requires a compatible X11 window manager such as gnome-shell/mutter and that would obviously only work for X11/Xwayland applications and not Wayland native ones.

I tried with gnome-shell in a Wayland session and opacity as set with EMWH's _NET_WM_WINDOW_OPACITY works on an X11 application so that's either that you're trying this on a Wayland native application or your Wayland compositor manager/window manager does not support X11 properties on X11 apps.

Can you give a bit more info on your setup?

Test:

1. Select "GNOME on Wayland" session in GDM
2. Log-in "GNOME on Wayland"
3. Run xterm
4. from xterm, type:
   $ xprop -format _NET_WM_WINDOW_OPACITY 32c -set  _NET_WM_WINDOW_OPACITY 0x7FFFFFFF
5. Click within the xterm window with the pointer (cross shaped cursor)

=> in gnome-shell running as a Wayland compositor and X11 window manager with xterm running in Xwayland, the xterm becomes half-transparent as expected.

The context is Fedora Rawhide fully up to date. There are two or three login options "GNOME", ["GNOME Classic"], "GNOME on Xorg". Some of my machines have the GNOME Classic option some do not, I have no idea what the algorithm is for this. However it doesn't matter as "GNOME" and "GNOME on Xorg" are the options that matter here.

I have an ancient Dell Precision T5400 workstation, Lenovo T500, Lenovo X201, and Lenovo X1. Currently there is a mouse settings problem all T5400, T500, X201, (reported but no activity as yet) but the X1 is working fine.

Experimenting on the X1, login to "GNOME" which is XWayland and XWayland from what I can tell. Run a GNOME terminal. Type in the xprop line above, click on terminal no response. Start an xterm, it comes up solid then when clicked on goes transparent and the xprop command terminates. I think this is the behaviour you were expecting?

So it seems that devilspie2 will need to do something very different for GNOME terminal (and I suspect many other things) and will have to allow itself to start when XWayland rather than XOrg is running so it can deal with XOrg applications as it has in the past.

Hopefully this is some of the "needinfo" needed?

Nope, that's not Xwayland but Wayland (GNOME on Rawhide uses Wayland indeed).

Xwayland is the rootless X server launched automatically by Wayland compositor to keep X11 compatibility with older X11 applications which have not been ported (yet) to Wayland.

But GNOME Terminal is Wayland native, so it's not running in Xwayland (like an older X11 application would).

Devilspie is for X11, it cannot work on Wayland native applications for several reasons:

 - Devilspie uses X11 properties defined in EWMH to control the appearance of applications in X11, that cannot work on Wayland as there is no X11 properties on Wayland native.

 - Wayland is a lot more secure than X11, an application (devilspie) cannot change the appearance or interfere with another Wayland application.

So devilspie cannot work in Wayland on Wayland native applications ,that's not a bug in Xwayland not devilspie.

If, with Wayland, all applications are their own masters (which clearly has some benefits) and applications do not provide an opacity capability (as the GNOME terminal people removed), then there is no way with Wayland to have all windows except some a given level of opacity – which is what I like and want. I really do not want all my windows to be fully opaque. 

If there is no way of getting opacity changes globally, I am going to have to find a new platform :-(

It sounds though as though this not a bug, but a feature request – one that can possibly never happen.

I guess this would a be a feature request for the wayland compositor to implement then, ie mutter or gnome-shell maybe (for GNOME).

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Has this been reported upstream?

(In reply to kxra from comment #10)
> Has this been reported upstream?

Yes: https://savannah.nongnu.org/bugs/?46746

Upstream is currently looking for a new maintainer. Marking as won't fix.