AFAICT that's something we should do

For some reason, MPV reports _NET_FRAME_EXTENTS properly, while every other window doesn't. The absence of this property results in any software that depends on it (i.e. picom) not working as expected under i3.

Any update on this issue? This problem has persisted for 2 years now. I would even do a PR to fix this problem but my knowledge in C is basically null.

I guess we can update the _NET_FRAME_EXTENTS Atom when updating the border values. Will look into it later

I'm afraid this isn't enough for picom to round the corner for windows with i3-title. picom currently round all edges of a window, which leads to this:

(Also you can notice that the shadow isn't rendered properly. Including the rounded corner issue, it's an excepted behavior, as technically they are two separate windows)

@yshui what's your opinion on this?

You should be able to select on the i3-frame WM_CLASS to distinguish those windows. If picom allows specifying border radii per corner, you can configure accordingly.

For split containers this still wouldn't work in 4.21 due to how it works, but with changes on the current main branch I think that issue should be resolved.

Hmm.

About the shadow issue, although picom have clip-shadow-above, it's not able to handle the case when two frames interferes.

Specifying border radius isn't possible now, but that should be easy to add.

I'm curious how (as in, why) it works for other window managers. Unless I'm missing something this wouldn't work for any window manager which reparents, which is pretty much all of them.

traidento@4a75314 tried the i3-rounded patch and seems it does not play nicely with borders and frames too.

just checked mpv and the title frame is acting weird too:

I'm curious how (as in, why) it works for other window managers. Unless I'm missing something this wouldn't work for any window manager which reparents, which is pretty much all of them.

A quick experiment says that the window title / window decorations are not the parent window of xterm, but an entirely disconnected window in i3.

When clicking on xterm itself:

$ xwininfo -tree -frame
[...]
xwininfo: Window id: 0x400326 "[i3 con] container around 0x5629954778c0"

  Root window id: 0x769 (the root window) "i3"
  Parent window id: 0x769 (the root window) "i3"
     1 child:
     0x300000e "xterm": ("xterm" "XTerm")  484x316+2+0  +717+380
        1 child:
        0x300001a (has no name): ()  484x316+0+0  +718+381

When clicking on the titlebar:

$ xwininfo -tree -frame
[...]
xwininfo: Window id: 0x40032a "[i3 con] floatingcon around 0x562995477a10"

  Root window id: 0x769 (the root window) "i3"
  Parent window id: 0x769 (the root window) "i3"
     0 children.

In other WMs, I would expect the xterm window to be a child of the window that contains the titlebar. Put differently: If xterm were 10x10 pixels large, the titlebar would be a window e.g. 10x15 pixels large with the xterm window at position 0x5 inside of this window. In i3 there are two completely separate windows on the same level of the window hierarchy which just happen to be next to each other.

Ugh, yeah. I'm beginning to remember we may also have a slightly odd structure for floating windows.

It also doesn't work well with tabbed/stacked mode as mention earlier, the i3-frame is a independent window in the tree.

I think the weird structure also caused this, but I'm not sure:
yshui/picom#892 (comment)

I've been playing with this a tiny bit and setting _NET_FRAME_EXTENTS to Con::current_border_width in x_push_node() seems to work more or less fine:

The only case where I see a bit of an issue is the tabbed layout where the titles don't get rounded but the windows do (though personally, I don't find that to be that big of an issue):

Would there be chances that a solution such as this would get accepted since from my POV it definitely feels better than not setting _NET_FRAME_EXTENTS at all and making rounded corners look broken with picom

well, with gaps it looks pretty bad I think

I think it looks just fine. What exactly don't you like? (is it not better than the current broken state?)

Some time ago I was trying to "fix" _NET_FRAME_EXTENTS for some old java application. Maybe someone find attached patch useful somehow.

From 264b5bfd9fdc2ee2fd0361c51aeb525386397167 Mon Sep 17 00:00:00 2001
From: Marcin Kurek <[email protected]>
Date: Sat, 30 Jan 2021 01:52:48 +0100
Subject: [PATCH] Try to dumb-set _NET_FRAME_EXTENTS

---
 src/manage.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/manage.c b/src/manage.c
index 8ea820d..bb8bdf9 100644
--- a/src/manage.c
+++ b/src/manage.c
@@ -545,10 +545,25 @@ void manage_window(xcb_window_t window, xcb_get_window_attributes_cookie_t cooki
     }
 
     /* explicitly set the border width to the default */
-    if (nc->current_border_width == -1) {
+    if (nc->current_border_width <= -1) {
         nc->current_border_width = (want_floating ? config.default_floating_border_width : config.default_border_width);
     }
 
+    /* _NET_FRAME_EXTENTS: approximate frame size */
+    Rect r = {
+        nc->current_border_width, /* left */
+        nc->current_border_width, /* right */
+        render_deco_height(),     /* top */
+        nc->current_border_width, /* bottom */
+    };
+    xcb_change_property(
+        conn,
+        XCB_PROP_MODE_REPLACE,
+        window,
+        A__NET_FRAME_EXTENTS,
+        XCB_ATOM_CARDINAL, 32, 4,
+        &r);
+
     /* to avoid getting an UnmapNotify event due to reparenting, we temporarily
      * declare no interest in any state change event of this window */
     values[0] = XCB_NONE;
-- 
2.29.2

(looks very similar to what I did)

I think it looks just fine. What exactly don't you like? (is it not better than the current broken state?)

Ivew meant the tabbed layout, sry, my anwser was quite out of context.

yes it looks better then the borcken state, but still, tabbed, just litteraly looks bad as heck

Ivew meant the tabbed layout, sry, my anwser was quite out of context.

yes it looks better then the borcken state, but still, tabbed, just litteraly looks bad as heck

Ah, yes, no worries, you're right. Currently, I don't think I have the time to investigate how to do this correctly with the tabbed layout and I would personally prefer to have this rather than the current broken state since it won't affect people who don't have rounded corners enabled

Anyway, I would definitely hope either I or someone else will have the time to fix this with the tabbed layout!

Hmm, so I am actually not sure how to make picom understand it shouldn't round the top borders of the tabbed windows. Originally, I thought it could be done through _NET_FRAME_EXTENTS but it doesn't seem to work for me :/

How about submitting a PR and asking about the tabbed layout? I don't know about the code but functionality-wise it looks great like that.

#5384 looked abandoned and not completely correct, so I created another PR (#5944) which tries to set _NET_FRAME_EXTENTS to the values which actually match the decoration sizes used by i3 (it turned out that con_border_style_rect() already exists and does almost all the job except converting the result to the format required for _NET_FRAME_EXTENTS).

In my testing the new code seems to give correct results for floating windows and tiled windows in simple split containers, but has the same appearance problem with windows in stacked/tabbed containers (the top frame extent is reported as 0, because the title bar for stacked/tabbed containers is not actually inside the X11 frame window for the client; picom still draws the rounded border in that case, but places it over the client area, obscuring some content). Looks like that problem is unsolvable without some major changes in the decoration handling for such containers.