How to exclude QT windows with client decorations?

[arielnmz]

Specifically in the case of Telegram (but I'm sure other QT based applications might have this issue) I see that the menus and other dialogs have this awful blurred space around them:

How do we tell compton to not blur and put shadows on them? I was looking for something similar to _GTK_FRAME_EXTENTS but either I can't figure out the right language to look for it or such a thing simply doesn't exist on QT.

This is what xprop can tell me about some of Telegram menus:

_NET_WM_USER_TIME(CARDINAL) = 6261168
WM_TRANSIENT_FOR(WINDOW): window id # 0x1c00006
_NET_WM_ICON_NAME(UTF8_STRING) =
_NET_WM_ICON(CARDINAL) = 	Icon (64 x 64):

[icon excluded]
    
XdndAware(ATOM) = BITMAP
WM_NAME(STRING) =
_NET_WM_NAME(UTF8_STRING) = "TelegramDesktop"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x1, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0x1c00008
WM_HINTS(WM_HINTS):
        Client accepts input or input focus: True
        window id # of group leader: 0x1c00008
WM_CLIENT_MACHINE(STRING) = "bc-1.bc"
_NET_WM_PID(CARDINAL) = 2
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 29360442
WM_CLASS(STRING) = "telegram-desktop", "TelegramDesktop"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        user specified location: 1012, 567
        user specified size: 186 by 220
        window gravity: NorthWest

[arielnmz]

So far I can use this rule to fix the popup menus:

_NET_WM_WINDOW_TYPE:a *= '_KDE_NET_WM_WINDOW_TYPE_OVERRIDE'

But the call dialog still has that weird blur between the frame and the client content:

[arielnmz]

No news on this?

[AdamantGarth]

I'm also having this issue. Thank you for a partial workaround though, @arielnmz.

Is there an issue comment or some documentation where it's explained why picom puts shadows on windows that other compositors do not? I never had an issue with shadows while using Mutter (and forks), Xfwm, Kwin or Compiz. If they're able to tell which windows shouldn't be decorated with shadows, picom should also be able to, right? No disrespect to developers, just genuinely curious.

[absolutelynothelix]

Is there an issue comment or some documentation where it's explained why picom puts shadows on windows that other compositors do not? I never had an issue with shadows while using Mutter (and forks), Xfwm, Kwin or Compiz. If they're able to tell which windows shouldn't be decorated with shadows, picom should also be able to, right? No disrespect to developers, just genuinely curious.

i believe that picom aims to be configurable and not to make assumptions instead of an user.

[arielnmz]

The problem is that picom does not allow writing rules that match values within properties e.g. _MOTIF_WM_HINTS[2] to check for specific WM flags. But there is already a solution in the works for that: #616

[OopsYao]

For me, adding _GTK_FRAME_EXTENTS@:c in the shadow and blur excluding rules fixes this, which comes from the sample config file.

picom/picom.sample.conf

Line 51 in 0141bfb

"_GTK_FRAME_EXTENTS@:c"

Picom version: vgit-98a5c.

[seqizz]

Sorry for necrobump, that extents thing doesn't work for the case sadly.

I realized I duplicated the same question here: #903 but so far no joy :)

[absolutelynothelix]

since this affects both telegram desktop windows and menus i'd do this:

shadow-exclude = [
  "class_g = 'TelegramDesktop'"
];

blur-background-exclude = [
  "class_g = 'TelegramDesktop'"
];

however, it's not a perfect solution.

[absolutelynothelix]

ah, i saw your pull request on this. if you claim that it fixes the described issue and you've been using it for a long time without other issues then it'd be good to have it merged:

1. either update and clean up your pull request (if it needs to be);
2. or ask @tryone144 to make a pull request himself.

then we need to ask @yshui to review the pull request.

[arielnmz]

Yup, just asked @tryone144 to make a PR... one note though, I didn't claim it fixes this issue, only that the feature to access raw properties in the rules works fine. Even if that feature is added, the tricky part is coming up with the right rule for some windows. e.g. I haven't found a way of matching this transient window in a gtk3 client

[meliurwen]

@arielnmz for your GTK issue try these rules:

shadow-exclude = [
    ...
    "window_type = 'menu'",
    ...
];

fade-exclude = [
    ...
    "window_type = 'menu'"
    ...
]

blur-background-exclude = [
    ...
    "window_type = 'menu'",
    ...
];

They work for gtk4 apps menus, but I'm not sure for gtk3's since I've migrated quite some time ago and don't really remember; this is my configuration in case you find something useful.

Btw what is the name of that emoji application so I can try to reproduce it.

[absolutelynothelix]

@meliurwen, unfortunately, this disables effects for all menus. they play nice with some menus, that's why people want to disable effects only for menus belonging to a particular applications.

[arielnmz]

@meliurwen the application is smile https://flathub.org/apps/it.mijorus.smile and yes as @absolutelynothelix I think that rule disables it for all menus, but gtk2 menus work just fine, i wouldn't want to lose the pretty effect on them 😄