qtile not respecting frameless window?

[tamis-laan]

Cross reference issue, qtile not respecting frameless window?

https://github.com/nextcloud/desktop/issues/3056

[tych0]

Can you post an xprop of said window?

[tamis-laan]

How to do this with a popup? I'm not in to wack a mole >_<

[tych0]

I'm not into fixing bugs that don't have a complete report :)

Try sleep 5s && xprop.

[tamis-laan]

_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0x0
_NET_WM_USER_TIME(CARDINAL) = 27431241
_VARIABLE_REFRESH(CARDINAL) = 1
WM_TRANSIENT_FOR(WINDOW): window id # 0x120001a
_NET_WM_ICON(CARDINAL) =    Icon (16 x 16):

    Icon (32 x 32):

    Icon (64 x 64):
    (not shown)
    Icon (128 x 128):
    (not shown)

XdndAware(ATOM) = BITMAP
WM_NAME(STRING) = 
_NET_WM_NAME(UTF8_STRING) = "Nextcloud"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x1, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG, _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0x120001a
WM_HINTS(WM_HINTS):
        Client accepts input or input focus: True
        window id # of group leader: 0x120001a
WM_CLIENT_MACHINE(STRING) = "laptop"
_NET_WM_PID(CARDINAL) = 32137
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 18874393
WM_CLASS(STRING) = "nextcloud", "Nextcloud"
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: 2475, 1253
        user specified size: 400 by 510
        window gravity: Static

[tych0]

I don't see anything specifically here about frameless-ness; _NET_WM_WINDOW_TYPE_DIALOG should cause it to float by default with git master, though. What's the misbehavior?

[tamis-laan]

It's a systray app and it's popup should not draw a border arround it: Ugly popup which conflicts with high dpi screens and does not respect the qt theme :-1:

[tych0]

I think we draw borders on everything that's floating, if you want dynamic borderless-ness it would need to be a patch to the floating layout to introduce some heuristics or user config to not draw this border.

[tamis-laan]

Well aparently windows can give hints as to not draw a border, and aparantly qtile does not respect these hints?

[tych0]

Well aparently windows can give hints as to not draw a border, and aparantly qtile does not respect these hints?

Yeah, seems that way. I don't see that hint in the xprop though, but maybe I'm missing it?

[ramnes]

I think we draw borders on everything that's floating

There are a lot of floating windows that we do not handle actually, and thus do not give borders, for example Chrome notifications. I never understood how that happens, but this may be the kind of window that should enter in that scenario?

[m-col]

There are a lot of floating windows that we do not handle actually, and thus do not give borders, for example Chrome notifications. I never understood how that happens, but this may be the kind of window that should enter in that scenario?

Override-redirect?

That xprop shows two window types:

_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG, _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL

Either that is strange or I've just never noticed -- possibly related?

[elParaguayo]

From a bit of digging, it seems that _NET_WM_WINDOW_TYPE was intended to replace _MOTIF_WM_HINTS but I don't see anything in the description about borderless windows.

However, it sounds like _MOTIF_WM_HINTS describes window decorations but I can't find a spec for it. It does seem from some searching that that property can be used for borderless windows.

EDIT: see in the i3 source: https://github.com/i3/i3/blob/62367c686d6b98902d26fff4f5e4ba7349c515d8/src/handlers.c#L1103-L1115

[m-col]

It seems like something that should set override-redirect but it doesn't. An example of something that does is firefox's notifications:

No (qtile) borders. The xprop for that window similarly doesn't show anything that obviously says "don't draw borders on me":

WM_HINTS(WM_HINTS):
        Client accepts input or input focus: True
        Initial state is Normal State.
        window id # of group leader: 0x1000001
WM_WINDOW_ROLE(STRING) = "alert"
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 2
XdndAware(ATOM) = BITMAP
_NET_WM_OPAQUE_REGION(CARDINAL) = 
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_UTILITY
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 16793533, 16793534
_NET_WM_USER_TIME(CARDINAL) = 26756615
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1003fbc
WM_CLIENT_LEADER(WINDOW): window id # 0x1000001
_NET_WM_PID(CARDINAL) = 2608
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "zenbook"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        program specified location: 0, 0
        program specified minimum size: 351 by 71
        program specified maximum size: 16384 by 16384
        program specified base size: 351 by 71
        window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "Alert", "firefox"
WM_ICON_NAME(STRING) = 
_NET_WM_ICON_NAME(UTF8_STRING) = 
WM_NAME(STRING) = 
_NET_WM_NAME(UTF8_STRING) = 

Another way to distinguish a floating window from an unmanaged window is whether or not you can drag/resize it. If I try to drag this notification then it moves the focussed window instead. Can you drag that window?

[m-col]

Or I guess you could just do qtile cmd-obj -o cmd -f windows :D

Anyway if it is there then I think it probably shouldn't be.

[tych0]

So what in our code decides not to draw borders?

[m-col]

When a window is created and mapped and it has the override-redirect flag set then we do not manage it, shown here. We don't manage it -> no borders drawn. This is common for transient windows such as popups.

[tych0]

I see, so the application should probably set that flag. We could probably add a "don't manage these windows" Match() list to config, for situations like this where it doesn't, or maybe just implementing support for _MOTIF_WM_HINTS as @elParaguayo describes is enough.

[m-col]

However, it sounds like _MOTIF_WM_HINTS describes window decorations but I can't find a spec for it. It does seem from some searching that that property can be used for borderless windows.

EDIT: see in the i3 source: https://github.com/i3/i3/blob/62367c686d6b98902d26fff4f5e4ba7349c515d8/src/handlers.c#L1103-L1115

When I run i3 with debug logging I don't get that log message printed with this window so maybe not... but I can't figure out how i3 is figuring out not to draw decorations it.

I see, so the application should probably set that flag. We could probably add a "don't manage these windows" Match() list to config, for situations like this where it doesn't, or maybe just implementing support for _MOTIF_WM_HINTS as @elParaguayo describes is enough.

The flag would certainly give it the behaviour that it seems to want (which is why I also commented on the Nextcloud thread) but it seems like i3 also seems to be "correctly" not drawing borders on it. But I cannot figure out how they're doing it!

[m-col]

That linked i3 function seems to be about changing that hint. I think here is where that hint is handled upon window creation.

edit: this might be useful if we do choose to implement handling of this hint.

[m-col]

More useful information from i3 here:

/**
 * Updates the MOTIF_WM_HINTS. The container's border style should be set to
 * `motif_border_style' if border style is not BS_NORMAL.
 *
 * i3 only uses this hint when it specifies a window should have no
 * title bar, or no decorations at all, which is how most window managers
 * handle it.
 *
 * The EWMH spec intended to replace Motif hints with _NET_WM_WINDOW_TYPE, but
 * it is still in use by popular widget toolkits such as GTK+ and Java AWT.
 *
 */

To summarise the situation:

• i3 is handling MOTIF_WM_HINTS and as a result is not drawing window decorations
• The nextclient client sets _NET_WM_WINDOW_TYPE which is intended to replace MOTIF_WM_HINTS so ideally we'd just handle that in a similar way
• to get similar behaviour we can either:
  • handle MOTIF_WM_HINTS in the same way as i3, or
  • implement _NET_WM_WINDOW_TYPE-specific border rules, possibly hooking config.Match into a per-window border setting that only needs to be used on floating windows.

The latter suggestion with a Match(wm_type="dialog) to remove borders would also remove borders from other dialog windows, such as many "Select a file" windows. Perhaps that is desired too? Interestingly the result of supporting MOTIF_WM_HINTS on i3 is that some dialog windows do get decorations (those without MOTIF_WM_HINTS such as Firefox' "Open file" dialog) and some dialog windows do not (those MOTIF_WM_HINTS such as Thunar's (GTK) "Preferences" window). This seems a bit inconsistent so I think that the most consistent approach would be to allow for setting border styles are the level of the window (only respected when floating) and probably also providing a default match for it, in which some of the window types can be added (not just dialogs, but also splash windows for instance). Thoughts?

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[elParaguayo]

If we're going to support motif hints, here's the definition:

typedef struct {
    uint32_t flags;
    uint32_t functions;
    uint32_t decorations;
    uint32_t input_mode;
    uint32_t status;
} MotifWmHints, MwmHints;

#define MWM_HINTS_FUNCTIONS     (1L << 0)
#define MWM_HINTS_DECORATIONS   (1L << 1)
#define MWM_HINTS_INPUT_MODE    (1L << 2)
#define MWM_HINTS_STATUS        (1L << 3)

#define MWM_FUNC_ALL            (1L << 0)
#define MWM_FUNC_RESIZE         (1L << 1)
#define MWM_FUNC_MOVE           (1L << 2)
#define MWM_FUNC_MINIMIZE       (1L << 3)
#define MWM_FUNC_MAXIMIZE       (1L << 4)
#define MWM_FUNC_CLOSE          (1L << 5)

#define MWM_DECOR_ALL           (1L << 0)
#define MWM_DECOR_BORDER        (1L << 1)
#define MWM_DECOR_RESIZEH       (1L << 2)
#define MWM_DECOR_TITLE         (1L << 3)
#define MWM_DECOR_MENU          (1L << 4)
#define MWM_DECOR_MINIMIZE      (1L << 5)
#define MWM_DECOR_MAXIMIZE      (1L << 6)

#define MWM_INPUT_MODELESS 0
#define MWM_INPUT_PRIMARY_APPLICATION_MODAL 1
#define MWM_INPUT_SYSTEM_MODAL 2
#define MWM_INPUT_FULL_APPLICATION_MODAL 3
#define MWM_INPUT_APPLICATION_MODAL MWM_INPUT_PRIMARY_APPLICATION_MODAL

#define MWM_TEAROFF_WINDOW  (1L<<0)

[jwijenbergh]

Still an issue as far as I'm aware

[jwijenbergh]

This bot is the new marvel villain

[ismasou]

I know the override-redirect windows are not managed by qtile, but is there a way they can be made to stay always above? When sharing the screen on zoom the toolbar is using this flag so it's not managed by Qqtile, but other windows can come above it and this makes it hard to stop sharing or to manage my share.

[elParaguayo]

I know the override-redirect windows are not managed by qtile, but is there a way they can be made to stay always above? When sharing the screen on zoom the toolbar is using this flag so it's not managed by Qqtile, but other windows can come above it and this makes it hard to stop sharing or to manage my share.

Can you post this as a new issue? It will get lost here as this was about something a bit different.