10:03 <FireFly> did something change around borders with the new release? I seem to have lost mine, tried to explicitly set `riverctl border-width` as well but I'm not seeing any..

10:04 <FireFly> wait oh, I bet this is the csd change..

10:06 <FireFly> yep, bingo.. hmm, that explains it, I think I'll just `riverctl rule-add ssd` for now but should reconsider what I want here

10:09 <FireFly> it's a bit curious though that without I get no borders in e.g. alacritty or firefox, even if I'd expect those to not provide their own client-side decorations/at least if they do I'd expect some window border and not just borderless window content

10:22 <ifreund> FireFly: It's totally up to the client how they draw (or don't draw) CSDs...

10:22 <ifreund> foot for example will add a title bar if told to draw CSD but will not draw its own borders

10:23 <FireFly> hmm right

10:24 <FireFly> and I guess it's just a binary either-or, as opposed to the client informing somehow which kinds of decorations it's drawn.. I wonder how other compositors handle this, since I'd guess fancier/floating ones for DEs and such certainly would have WM borders for programs like firefox or terminal emulators

10:30 <ifreund> FireFly: I think gnome relies on drop shadows rather borders for gtk stuff for example

10:31 <ifreund> another thing that plays into this is that river sets the xdg-toplevel "tiled" state for windows in the tiled layout which causes e.g. gtk to not draw drop shadows

10:31 <novakane> that makes me curious to see foot with CSD and I've just realised that rule-add update all views but not rule-del

10:31 <novakane> learn something everyday :P

10:32 <ifreund> rule-del doesn't? sounds like a bug...

10:32 <ifreund> ah no that actually makes sense

10:32 <ifreund> with no csd/ssd rule we let the clients choose

10:32 <FireFly> aha

10:33 <ifreund> if there has been an enforced csd/ssd default in the past then it's too late to take the clients default

10:33 <FireFly> neat, I didn't know there was a way for WMs to hint at the "type" of WM they are (re. xdg-toplevel tiled state)

10:34 <novakane> yeah makes sense

10:34 <ifreund> gnome uses the "tiled" state as well afaik when it has tiled windows

10:36 <novakane> ifreund: btw have you any idea about this weird transparent bug for Firefox?

10:36 <ifreund> nope, right now I suspect a firefox bug

10:37 <ifreund> nobody can reproduce it with anything else right?

10:37 <ifreund> I was gonna try on my old thinkpad as well, might have better luck there

10:37 <ifreund> I can't get anything useful out of the WAYLAND_DEBUG=1 log, it's too much and too noisy

10:38 <ifreund> wlhax would probably be useful here

10:38 <novakane> I only have Firefox in gtk apps I think

10:38 <ifreund> novakane: if you want to play around with wlhax that might be interesting... have you tried it before?

10:38 <ifreund> https://git.sr.ht/~kennylevinsen/wlhax

10:39 <novakane> right I tried to get the smallest log but it's impossible

10:39 <novakane> yeah I used it for zelbar, I can test it

10:40 <novakane> what info would be useful?

10:40 <ifreund> I think the other approach that could lead to better understanding/a fix would be for me to add a bunch more debug logging to river that dumps firefox's scene tree in a readable format

10:47 <ifreund> hah! I can reproduce it on my x220

10:49 <novakane> well damn I can't reproduce it with wlhax env set xD

10:49 <dnkl> foot _can_ draw border... it's just that the default is a zero-pixel border (though I've been considering changing the default)

10:50 <ifreund> ah, TIL :)

10:51 <ifreund> novakane: too bad, race conditions can be like that...

10:52 <ifreund> for me firefox is cutoff on the top as well by the way, just not by as much as it's cut off on the left side

10:52 <ifreund> I turned off borders and gaps entirely and used a contrasting background to reproduce

10:53 <novakane> yeah, race conditions are rhe worst too debug

10:54 <novakane> I don't think the top is cut for me, although I can see a frame where it seems like it has some round corners

10:55 <novakane> oh yeah it cuts the top if I remove my bar

10:57 <ifreund> yeah, that makes sense

10:58 <ifreund> I think mine's cut off by the same amount as in your screenshots

10:58 <ifreund> I wonder why the original reporter has so much more cut off

10:58 <ifreund> I guess the gtk theme they are using or something...

11:05 <novakane> yeah could be, make it way more noticeable for them, at least this allowed a bug report

11:20 <ifreund> ok, I've got a setup where I can reproduce it under wlhax

11:21 <novakane> nice, hopefully it has some useful info

11:38 <ifreund> so yeah, pretty sure it's a firefox bug :/

11:38 <ifreund> we can work around it though

11:40 <ifreund> or maybe it's technically allowed by the protocol but just weird/dumb

11:54 <leviathan> I noticed someone asking about the input-method-v3 popup in the log. I opened a draft PR to implement it  and have been using it for three weeks now. It's working well so far.

11:57 <leviathan> I marked it as a draft because I got caught up in some crazy busy stuff and haven't had the time to polish the code further.

11:58 <novakane> ifreund: if at least we can work around it that a good start

11:59 <ifreund> novakane: pushed a fix already :)

11:59 <ifreund> leviathan: take your time, no pressure :)

11:59 <leviathan> Furthermore, in my opinion, the actual implementation of the Input-method-v3 protocol is likely to be heavily dependent on how the IME software utilizes this protocol.

11:59 <leviathan> I find it quite difficult to determine the specific requirements that I need to implement.

12:00 <leviathan> I may have sufficient time to continue investigating these matters in the next few days.

12:03 <ifreund> you mean like where to place the popup depends on what the IME renders to the popup surface?

12:04 <novakane> ifreund: yeah seems to fixed for me too, there is clearly one or two imperfect frame but no more transparency

12:04 <ifreund> excellent :)

12:07 <leviathan> Perhaps I didn't express myself clearly. Using fictx5 as an example, it seems that it didn't even use the text_input_rectangle method of the input-method-v2 protocol.

12:07 <leviathan> However, this is the only method of the input_popup_surface_v2 protocol.

12:10 <leviathan> I even saw the fcitx5 developers discussing the idea of implementing the functionality, including positioning and  popup, independently within the IME, instead of using the input-method protocol to handle various interactions.

12:14 <ifreund> leviathan: I'm not sure I understand. The IME client doesn't have any control over where the compositor places the input method popup

12:14 <ifreund> the text_input_rectangle of the input-method-v2 protocol informs the client of where the popup was placed