With shadow = true, Compton draws a shadow below the transparent autoscroll cursor of Firefox, which looks really ugly. This not just because it is undesired, it's also because the shadow is a perfect square, while the cursor has the shape of a circle.
This can be easily worked around by using shadow-exclude = "class_g = 'Firefox' && argb" or shadow-exclude = "class_g = 'Nightly' && argb".
I just wonder if there is a way to exclude the cursor automatically?
Though I really like that Compton by default always draws shadows. kwin_x11 lacks them for GTK UIs, which is way more annoying than excluding some elements.
I don't think there is a reliable and consistent way to detect this kind of windows. I also don't want compton to become too "smart" for the user to figure out what is going on.
Do you have suggestions what is the best to do?
Imho it's generally hard to decide what is one's personal taste and what common sense. But I think for rare and evident cases like this, we could have a default list of excluded elements.
Often it is recommended to exclude aspects of the desktop environment's shell from shadowing, but e.g. I personally quite like the shadows of taskbar menus for Plasma shell, to make them appear popped out when I'm using them.
One thing I'm not sure about is dragging of objects with the mouse, e.g. bookmarks in Firefox.
Many compositors don't draw shadows beneath them. On the other hand, with transparency it helps to maintain visibility.
Btw: I noticed an undesired white underlining when dragging opaque elements in Firefox. Should I create a new ticket for it?
Right, it might help if we ship some helpful rules in the sample config (there are already a couple there), but I don't think it is a good idea to hardcode a set of default rules.
white underlining when dragging opaque elements in Firefox
That's probably just what firefox does, I don't think that is a bug.
For some reason, Firefox main window doesn't draw shadows anymore on top of other windows when using --shadow-exclude =
"class_g = 'Firefox' && argb". I think this has happened due to a change in Firefox' theming/windowing, as it still works correctly in Thunderbird.
@aufkrawall: I came up with this when that same problem showed up in the Nightly version:
"(class_g = 'Firefox' || class_g = 'Nightly') && window_type = 'utility'"
That "utility" type seems to catch everything problematic while leaving the main window and the right-click menu alone.
@Ropid Thanks a lot, it works.
With Firefox v68.0.1, the exclude rule for pop-ups has to change to the following:
"class_g = 'firefox' && window_type = 'utility'"
Apparently they changed the window class name to lower-case "firefox". Previously it was "Firefox".
I want to document here how to research the window properties for pop-ups because how to do it is not obvious at all:
sleep 5; pkill -STOP firefox; setxkbmap -option grab:break_actions; xdotool key XF86Ungrab
This command line does the following:
At this point, you can then run xprop to research the frozen pop-up window. Afterwards send a CONT signal with pkill -CONT firefox to unfreeze the program.
Most helpful comment
With Firefox v68.0.1, the exclude rule for pop-ups has to change to the following:
Apparently they changed the window class name to lower-case
"firefox". Previously it was"Firefox".I want to document here how to research the window properties for pop-ups because how to do it is not obvious at all:
This command line does the following:
At this point, you can then run
xpropto research the frozen pop-up window. Afterwards send a CONT signal withpkill -CONT firefoxto unfreeze the program.