05:16orowith2os[m]: zzag: did you still have an interest in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/43 ?
05:17orowith2os[m]: Inochi2D (libsoba, specifically) would like to make use of it
05:18orowith2os[m]: it would need to be able to shade it to the UI color, though
05:20orowith2os[m]: basically, it would need to be more like what Windows and macOS provide
05:20orowith2os[m]: for an end result, not the API, if it's a security concern
05:23orowith2os[m]: I was recommended to look at the macOS impl for reference, apparently it's pretty flexible
08:35soreau: V: please fix your connection to avoid rejoining the channel so often
08:48soreau: I really don't understand the logic behind clients that want to specify their own blur regions. The only argument that holds merit is the fact that most users don't want blurring behind drop shadows, a problem complicated by CSD and rounded corners. The compositor blur shader could detect a special ratio of color elements the client sets for shadows, normalize them and don't apply blur for that pixel
08:52soreau: I'm not sure if setting negative values can carry through to the shader, but that might be convenient
11:31daniels: vyivel:
11:32daniels: oops :)
16:51orowith2os[m]: soreau: maybe it would be easier if the protocol worked with wl_surfaces instead?
16:52orowith2os[m]: I'm not sure if "all we need" would be entire appropriate to use here, as it might be downputting the amount of work needed to get this going
16:55orowith2os[m]: maybe a shadow protocol would be useful for this too, so that apps can get shadows (also means the user decides here)?
16:56orowith2os[m]: I know KDE also has that, I just don't know if Mutter can, or would be willing to, implement that
17:01orowith2os[m]: jadahl: curious to see if you'd be able to comment...?
17:04orowith2os[m]: what do you think it might look like if GTK/Libadwaita added methods to get something like https://learn.microsoft.com/en-us/windows/apps/design/style/mica ?
18:14soreau: orowith2os[m]: it would be easier if there were no protocol
18:15soreau: this is surface is partly blurred https://imgur.com/Hl89pQC
18:16soreau: but for the compositor to not blur shadows.. I guess you could take the input region, minus a few pixels for corner radius and assume the decoration border is opaque
18:17soreau: for clients to start spewing about what it thinks should be blurred, this is not useful from compositor POV IMHO
18:57zamundaaa[m]: soreau: assuming that the input region is to be blurred is pretty bad
18:57zamundaaa[m]: You have no idea what resolution the input region is in, and it can extend past the visible surface
19:09soreau: zamundaaa[m]: I use 'input region' term loosely as xdg shell configure bounds
19:09zamundaaa[m]: That doesn't work either
19:09zamundaaa[m]: This isn't just about xdg shell, and rounded corners exist
19:10soreau: anyway, even if you had such a protocol, some compositors plain won't support it because they don't want to or don't even have a blur feature (pixman?)
19:10zamundaaa[m]: Sure. What exactly is the problem with that?
19:10soreau: it's kinda like saying 'the window shall burn exactly as the client specifies'
19:11soreau: it's just kinda ridiculous to think the client knows better than the compositor in this case
19:11zamundaaa[m]: Not in any way or form, no
19:11soreau: blur is candy, not a well-defined effect
19:12zamundaaa[m]: So?
19:12soreau: so there shouldn't be any protocol for it
19:12zamundaaa[m]: That's not an argument for anything
19:13zamundaaa[m]: We don't even have a definition for how blending is done. Will you next argue that transparency should be forbidden because there's no exact definition for it?
19:13soreau: not forbidden, but to-be-handled-by-$compositor
19:13soreau: not by some buggy client
19:14zamundaaa[m]: Transparency isn't done by the compositor
19:14soreau: anyway, this is fine for a compositor-specific protocol
19:14soreau: but doesn't have a place in upstream protocols
19:15zamundaaa[m]: That's not for you to decide
19:26soreau: zamundaaa[m]: what are your particular use cases?
19:27soreau: is it so apps can turn blur on and off in app settings? not blur the shadows? something more?
19:28zamundaaa[m]: In Konsole, it's so that its profiles can turn it on or off, yes
19:29zamundaaa[m]: In the panels, it's for specifying the actual region though. Because rounded corners, and because the window is bigger than the visible bits in some cases
19:31soreau: so the panel you're describing has rounded corners with drop shadows?
19:32zamundaaa[m]: Yes
19:32soreau: in addition to being semi-transparent in the 'main area'? (trying to avoid input-region term)
19:32zamundaaa[m]: Yes
19:32soreau: the problem I see happening is that the compositor goes out of its way to honor the region and the client gets it wrong, so you end up with something really ugly on the screen
19:33zamundaaa[m]: Umm no
19:34zamundaaa[m]: That's about as much a problem as the client rendering into the parts of its surface that should be transparent
19:51soreau: you mean rendering transparent where the opaque region covers?
19:52soreau: hm, it seems gtk3 only puts drop shadows on focused windows(?)
19:54orowith2os[m]: Discord on Wayland has a shadow when it's not focused on my end
19:54orowith2os[m]: dconf-editor as well
19:55soreau: must be a theme thing
19:57soreau: but if you want a protocol that only allows toggling blur and rounded corner definitions, the only communication you would need is a request to toggle and another to set corner radiu
19:57orowith2os[m]: not sure, I'm not using any sort of gtk3 themes
19:57soreau: +s
19:57soreau: the compositor can figure it out from there
19:58orowith2os[m]: interesting, I guess. I wonder how Windows handles with Mica applications that want a fully transparent section of the window?
19:58soreau: just.. render alpha = 0 there?
19:59zamundaaa[m]: Alpha=0 doesn't mean you don't want it blurred
19:59soreau: what?
19:59soreau: you want a blurred area that is also fully transparent?
19:59soreau: why would you want this?
19:59zamundaaa[m]: Why not?
19:59soreau: because it's ridiculous
19:59zamundaaa[m]: Why?
19:59orowith2os[m]: you'd want a blurred window, but a fully transparent window within it
19:59orowith2os[m]: er, area, not window
20:02orowith2os[m]: but a blurred, fully transparent background would also do it
20:03soreau: zamundaaa[m]: I just don't think it makes sense in terms of reality
20:03soreau: if there's a hole in a wall, why would things be blurry when looking through it?
20:03orowith2os[m]: I'll raise you this: https://flathub.org/apps/com.inochi2d.inochi-session
20:04zamundaaa[m]: soreau: why would a visual effect need to be based in reality?
20:04zamundaaa[m]: How blending works in pretty much every compositor also has nothing to do with reality
20:04zamundaaa[m]: Doesn't make it ridiculous
20:04soreau: ok, I'll live over here in reality, and you can live wherever it is that you do
20:05orowith2os[m]: the UI toolkit Inochi Session is going to use in the future would like to use a blur protocol, and would have a transparent background for the areas of the window that aren't covered in a UI element. It might want a fully transparent background, or a blurred one, depending on situation.
20:05orowith2os[m]: if you want to think in terms of reality?
20:05soreau: 'we need to copy something elses future!'
20:05soreau: sounds convincing
20:06orowith2os[m]: it should be. Applications coming from a Windows or macOS background already make use of this, and in this case, Linux is the only platform that doesn't.
20:06orowith2os[m]: it's consistency.
20:09orowith2os[m]: besides, if you use the justification of "we don't need to copy something else's future", why are we adding Wayland protocols? That's the future, of applications using those protocols. It's a broken argument.
20:11orowith2os[m]: And if you want to look at something in the present on Linux, you could very well point at X11, but then it gets rejected because "we shouldn't be copying everything from X11"
20:11soreau: well considering the unrealistic case of 3D transformed surfaces, such as partly rotated around x/y axis, using a blur region, how would you render the drop shadows without blurring? sounds like there would be some ugly edge cases
20:12orowith2os[m]: oh, absolutely. And that's why a blur protocol is purely cosmetic. You don't need it to function.
20:12soreau: it's much easier and sane from compositor perspective to just blend blur based on alpha, like > 0.25 is blurred and less than that is blended
20:13orowith2os[m]: just to clarify: libsoba is going to support Linux, either way. It'll just do so without window blurring if this isn't a thing when the time comes.
20:14soreau: I guess I think of client-compositor protocol as the nuts and bolts and the rest can fall to compositor specific communication side bands/custom protocols
20:15zamundaaa[m]: Oro (any/all) It's already a thing. This is just about upstreaming an existing protocol that we've been using for many many years, and that at least two other compositor authors have asked us to upstream
20:16soreau: zamundaaa[m]: what prevents the others from just using what kwin does?
20:16orowith2os[m]: zamundaaa: I tend to take the mindset of "if it's not upstream, it doesn't exist" when it comes to applications wanting to support several compositors
20:17orowith2os[m]: (exceptions for groups like wlroots, of course)
20:18orowith2os[m]: but I think the end result of what soba is looking for here is a slightly more customizable blurring protocol
20:19orowith2os[m]: that way UI elements get their blur (and blurred according to how soba wants it, though I'm not sure if just using alpha settings does that job?), and fully transparent areas don't get blur if requested
20:20orowith2os[m]: e.g. having the ability to request custom blurring algorithms would be amazing in the future
20:21orowith2os[m]: er, not really custom, but well-defined blur algorithms that the compositor implements, that way it doesn't have to worry about CVEs
20:21soreau: what about blur strength, algorithm, performance and saturation? there's like an infinite number of knobs you could put on this thing and for blurring compositors to follow along with every change just seems unreasonable
20:23soreau: you might as well have a protocol request to upload a shader path to use
20:23orowith2os[m]: that's a big jump
20:24soreau: (not too far fetched, wayfire's filters plugin allows custom shaders for a surface or entire output)
20:24orowith2os[m]: a well-defined set of algithms, saturation, and maybe some other stuff UI toolkits expect would be plenty
20:25soreau: yea, that's really asking way too much
20:25orowith2os[m]: i don't think so, but that's up to compositors to decide. Ideally they wouldn't have to support every single blur algorithm out there.
20:26zamundaaa[m]: Oro (any/all): KDE's contrast protocol has some arguments like that, but tbh we've been looking at how to get rid of that...
20:26zamundaaa[m]: Either way, I don't think everything needs to be solved at once
20:26orowith2os[m]: I think just saturation and strength would be enough for now, in an ext-blur protocol
20:27orowith2os[m]: I also think, for apps to be able to reliably expect what type of blurring algorithm the compositor uses, being able to select one would be fine. The initial protocol can just define one or two options.
20:27soreau: it would be better for configure bounds request to grow a corner radius arg. compositors can already offer ways to blur only certain surfaces
20:27orowith2os[m]: corner radius would also be helpful ^^
20:28soreau: for blurring alpha = 0, that's just nuts
20:28orowith2os[m]: blurring alpha = 0.1 :)
20:29orowith2os[m]: I guess we go back down the rabbit hole in telling the compositor what alphas should be blurrable, when setting a region to not be blurred would be better
20:30soreau: then if there's a setting in the compositor to blur certain surfaces and the client has a setting too, then they have to both be enabled to get blur of any kind
20:31soreau: unless the compositor just ignores the protocol, as we've been doing all this time
20:31zamundaaa[m]: soreau you're going on and on about non-issues. We've had this blur protocol for 9 years, and the "problems" you're talking about are just not a thing
20:32zamundaaa[m]: Oro (any/all): unless there's significant complaints from people that can vote on the protocol MR, I'm going to go ahead with just upstreaming it as-is
20:32soreau: zamundaaa[m]: I think they're only *not* problems if the compositor goes above and beyond out of its way to support this
20:32zamundaaa[m]: More options, fixes or adjustments can be added later on
20:33soreau: zamundaaa[m]: so when a compositor doesn't support the protocol, what does the client do, alpha = 1 for all pixels?
20:33soreau: because that would be spectacular
20:33orowith2os[m]: zamundaaa @zamundaaa:kde.org what's a "significant" amount? Would expecting it to model similar APIs for window backgrounds on things like macOS be too much?
20:33zamundaaa[m]: That's up to the client, but yes, it may change to be less or not transparent at all
20:34zamundaaa[m]: IIRC plasmashell does change depending on if the contrast and blur protocols are supported
20:34soreau: zamundaaa[m]: because if you set alpha != 1 and get blurred, the client setting won't do anything
20:35zamundaaa[m]: Oro (any/all): adding a mode where the blurred background is the wallpaper and not what's behind the window could be done later
20:36soreau: that's a compositor feature, not a client..
20:36zamundaaa[m]: It could be, sure
20:36soreau: man, I am surprised that anyone wants clients to be 'in control' of blur
20:36orowith2os[m]: zamundaaa: I suppose so. Even just having the protocol as-is is a great help.
20:37orowith2os[m]: I challenge you to have apps that support Mica-style effects without having the client be somewhat in control of blur
20:37orowith2os[m]: and not just forcing it onto all apps
20:37soreau: zamundaaa[m]: and then if there is no background, then what? garbage?
20:37soreau: it seems like the compositor is in the position to know what to do better than the client
20:37orowith2os[m]: no blur
20:38zamundaaa[m]: Discussing the exact details of a protocol addition that hasn't even been proposed yet is useless
20:38zamundaaa[m]: So let's just not do that
20:39orowith2os[m]: I'm curious, what happens with clients that allow transparency?
20:39orowith2os[m]: they're not guaranteed of any behavior, are they?
20:40orowith2os[m]: so I could very well have a black transparent area on any window in a given context
20:40zamundaaa[m]: Oro (any/all): in principle, yes
20:41zamundaaa[m]: In practice, if a compositor doesn't allow transparency at least between the client's own surfaces, things are expected to break
20:41zamundaaa[m]: and look weird if it doesn't allow it to other surfaces too. Because CSD is a thing
20:41orowith2os[m]: fun
20:42orowith2os[m]: I think when I was playing around with capturing transparent X11 windows on Wayland, they completely broke in OBS
20:42orowith2os[m]: haven't tried with a native wl app yet, I don't think
20:43zamundaaa[m]: assuming you were using the xdg portal to get the window contents, that really shouldn't happen
20:44orowith2os[m]: it might also be an app problem, not sure
20:44orowith2os[m]: I have it installed right now, gonna test it
20:44orowith2os[m]: oh, I suspect it's broken.....
20:45orowith2os[m]: it allows me to set a background alpha (0-255) and it straight-up does not work
20:46orowith2os[m]: wl and x11
20:46orowith2os[m]: oh well
23:05DemiMarie:hopes for ext-zones to be upstreamed