04:11 bonecchi: Hello everyone
04:11 bonecchi: Is background blur not possible as of now on wayland? Can't find any info portraying to that
04:36 orowith2os[m]: bonecchi: AFAIK it's just clients being able to tell the compositor what regions of their window are transparent or opaque, and the compositor deciding what to do from there
04:38 orowith2os[m]: there's a bit of demand for more advanced things, the main concern is the compositor messing something up (so the app doesn't look Nice™), or security (apps blurring themselves, and basing it off of what's behind the window)
04:38 orowith2os[m]: not sure how much the last bit holds up
04:42 bonecchi: so basically every client needs to develop a solution for this
04:42 orowith2os[m]: not really
04:42 orowith2os[m]: they don't need to do anything
04:43 orowith2os[m]: and first up, a blur protocol or smth needs to be available in Wayland
04:43 orowith2os[m]: (which did have a proposal somewhere)
04:43 ammen99[m]: bonecchi: every wayland compositor has to develop a solution, see for example hyprland, wayfire and some sway forks which have blur
04:45 ammen99[m]: a blur protocol would only help if you want to blur parts of a window
04:47 orowith2os[m]: the initial use case for blur that I would have would be simulating Mica
04:47 orowith2os[m]: see: https://learn.microsoft.com/en-us/windows/apps/design/style/mica
04:48 bonecchi: I'm running river wm and I don't think they're gonna do that any time soon if at all
04:49 bonecchi: I guess I shall try hyprland, although it feels like I've tried it at some point
04:51 bonecchi: Never tried W11, must be something good if you want to simulate it
06:20 kennylevinsen: bonecchi: kde has a protocol for blur, not possible without as the transparency blending is done by the compositor
06:21 kennylevinsen: It is not possible for clients themselves to figure out what is "beneath" to create a blur
06:21 kennylevinsen: https://wayland.app/protocols/kde-blur
06:30 davidre: There was also a proposal to upstream it
06:31 davidre: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/43
06:32 orowith2os[m]: mm, I should clean up this issue later: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/136
06:32 orowith2os[m]: it would allow apps to do blur themselves, which is more what we'd (Inochi2D/libsoba) would want here
06:33 orowith2os[m]: but there's still the issue of security
06:34 bonecchi: that's why I'm asking, wouldn't the nature of wayland make this impossible
06:34 orowith2os[m]: there's always the possibility of just telling the compositor what the app wants, but that would be really nasty....
06:36 orowith2os[m]: in any case, the plan is just to not support Spica (libsoba's own Mica) on Linux because of it, which isn't too big of a problem - we have the accent color and the general design to make it look nice
06:36 davidre: With desktop image protocol you would always blur the desktop even if the window is not directly on the desktop but other windows are in between?
06:36 orowith2os[m]: yep
06:36 davidre: But that's desired in that design Case you are looking at iiuc?
06:37 orowith2os[m]: window contents aren't an interest, but the user background could contain private info (photos), which is what I'm worried about
06:37 davidre: Got it!
06:38 davidre: With a general compositor does blur protocol of course your compositor could just do that as well if you are worried
06:38 dottedmag:wonders if anyone writes down their passwords on the background picture
06:39 davidre: I can imagine on Plasma writing them into note taking applets on the desktop :D
06:40 orowith2os[m]: David Redondo: so long as the compositor is required to blur things in a specific way as specified by the client, sure - but that doesn't play well with Wayland's entire design still
06:40 orowith2os[m]: (client telling the compositor what to do)
06:41 orowith2os[m]: the main desire is: the client has full control over what goes on, and doing the blur itself is the most ideal situation here
06:41 davidre: I was thinking Client says region x is blurred. Your compositor would do desktop image thing, KWin would do the blur like now.
06:41 davidre: Ah ok that's not desireable for clients maybe to much variance in appearance
06:42 orowith2os[m]: mhm
06:42 orowith2os[m]: that's why the issue is about grabbing the desktop image, not letting the compositor handle it
06:42 davidre: I think there's a portal to set the desktop image
06:43 davidre: You can't get it out atm can you?
06:43 orowith2os[m]: I don't believe so
06:43 davidre: https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Wallpaper
06:43 orowith2os[m]: but ideally we would be able to do this all smoothly
06:43 orowith2os[m]: using a portal for this goes quite a bit against that
06:46 orowith2os[m]: also, we want to be able to get just what's below the current window
06:46 orowith2os[m]: not the entire thing
06:46 dottedmag: Does it make any difference, security-wise?
06:46 orowith2os[m]: and we need to do so a lot (resizing, moving, etc)
06:47 orowith2os[m]: what does?
06:47 dottedmag: grabbing only a part under the current windo
06:47 dottedmag: *w
06:47 orowith2os[m]: not much, but it helps
06:50 orowith2os[m]: I'd like some thoughts on this from jadahl and emersion, Jonas being the person here I'm familiar with the most
06:50 kennylevinsen: Wallpaper is not a fixed entity - there might be none, it might be animated 3D graphics, it might be an ever changing image...
06:51 kennylevinsen: And transparency without window content looks really weird. I recall some terminal emulators implementing this a decade ago.
06:52 orowith2os[m]: tl;dr: allow clients to see what the background is below their windows (no other window contents, just the background), to allow blur effects akin to Mica from Windows without getting into some annoying uncertainties
06:52 orowith2os[m]: transparency on its own is already handled, IIRC?
06:53 kennylevinsen: The frosted glass effect (both windows and mac style) require the compositor to make a special blurring pass
06:53 orowith2os[m]: yeah: https://wayland.app/protocols/wayland#wl_surface:request:set_opaque_region
06:53 orowith2os[m]: mmm
06:54 orowith2os[m]: IIRC on Windows it's handled client-side, but I didn't look too much into it, so could be wrong
06:54 kennylevinsen: Opaque region is an optimization, all windows allow transparency by default when a pixels alpha value is less than 100%
06:54 orowith2os[m]: noted
06:54 orowith2os[m]: also, ah, just grabbing one portion of the background at a time might not be the best
06:54 orowith2os[m]: "Mica is specifically designed for app performance as it only samples the desktop wallpaper once to create its visualization."
06:55 orowith2os[m]: so the windows would need to know where they are in relation to the background
06:55 orowith2os[m]: as well as access to the full background itself
06:55 orowith2os[m]: I think this is the time where I nope out
06:56 kennylevinsen: Client side frosted glass would imply being able to see beneath a window "how does a fully composited desktop look if you stop at Z-height just before my window")
06:57 kennylevinsen: No idea how the Windows API looks, but I do not see a way to do this without having the compositor do special composition passes to reveal the blue target
06:58 kennylevinsen: Whether to reveal it as a screenshot to the client wanting to blur or to perform the blur itself
06:59 orowith2os[m]: kennylevinsen: not a fully composited desktop, but access to the background image and window position
07:00 orowith2os[m]: the client can figure it out from there
07:00 orowith2os[m]: (also, not sure what "blue target" is)
07:03 kennylevinsen: yeah but a background isn't a well defined thing (in most wlroots compositors, the wallpaper is effectively just a window), and even if you have the image you need to know you window position to intersect correctly...
07:04 kennylevinsen: and well that would also only work for mica
07:04 orowith2os[m]: yeah, pretty niche use case
07:04 kennylevinsen: Everyone else to my knowledge expect proper frosted glass
07:06 kennylevinsen: Ah I just remembered the worst part of client-side transparency - synchronization
07:07 kennylevinsen: When the window moves, the client would need to react to position changes and rerender the effect - which would have a delay, leading to wonky imperfect frames
07:10 kennylevinsen: I guess a blur protocol could have a mica "wallpaper only" mode to do this effect correctly without all the negatives...
07:19 soreau: at best, the protocol will not be supported by compositors because it will just make a mess of the code and the desktop
07:20 soreau: it doesn't really make sense to have client control for this feature IMO
07:23 orowith2os[m]: it's a really strong desire from the primary user (libsoba) here to have it be client-managed, but it's probably not going to happen anyways
07:23 orowith2os[m]: can just leave it at that
07:24 wlb: wayland-protocols Issue #136 closed \o/ (Desktop image protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/136)
07:25 kennylevinsen: yeah the best answer to libsoba is "that's a bad idea" - the reasonably best case outcome of such approach would be a laggy effect :/
08:24 jadahl: the discussion about client side "transparency" (reading the X11 root window content) and laggyness reminds me of running Eterm around the year 2000
08:28 kennylevinsen: lol I wonder if that is the term in thinking of - Only thing I remember was the distinct delay if I moved the windo, and the illusion break when things overlap
08:52 jadahl: kennylevinsen: the introduction of actual transparency was incredible, but also meant I could see through to the other terminal windows and all their text which made it worse :(
15:38 immibis: what's the deal with client side decorations, why are clients supposed to render their own decorations thereby implementing part of the window manager themselves?
15:44 soreau: immibis: it's a choice of the client, there is a protocol to communicate to the compositor if the client intends CSD, SSD or no decorations
15:44 immibis: but I've read that almost no compositors support SSD
15:45 soreau: Use a compositor that does?
15:50 kennylevinsen: Many servers support SSD's, but use libdecor if you want decoration without thinking about it
15:55 wlb: weston Issue #809 opened by Link Mauve (linkmauve) Segfault when running mpv --vo=dmabuf-wayland after a while https://gitlab.freedesktop.org/wayland/weston/-/issues/809
16:06 wlb: wayland Issue #406 closed \o/ (Copy/paste popup does not appear when clicking menu button in squeekboard on foot or gnome-console https://gitlab.freedesktop.org/wayland/wayland/-/issues/406)
16:06 immibis: soreau: you think i get to decide which compositor my users use?
16:09 soreau: on the client side, you can probably fall back to CSD if the compositor doesn't support the decoration protocol or SSD
16:10 soreau: but really the best thing to do is communicate what you want, document the expectations and let the users decide for themselves what type of experience they want
16:27 boud: I'm actually trying to find out which package is responsible for 'message-missed-notification' after gsd-power notifies about "Automatic suspend" and goes ahead and suspends anyway.
16:28 boud: (Because the user didn't cancel the suspend.)
16:28 boud: It's pointless alerting the user that s/he didn't prevent his/her mobile phone from suspending to save power.
16:31 boud: Sorry - wrong channel! ignore my last three lines.
16:32 immibis: soreau: what is the point of SSD (whose entire point is that clients don't have to implement their own decorations) if you have to have the fallback anyway (you have to have the code for your own decorations)
16:32 immibis: this is actually a stupider situation than in X11
16:33 psykose: what is the point of csd when you implement your own decorations but the compositor might prefer ssd so you have to turn them off?
16:33 psykose: it's the same shit both ways
16:34 immibis: that too!
16:34 ebassi_: The other side is: why should the window manager draw the decorations? Who decided that it should be part of the WM, when clients are perfectly capable of doing that?
16:35 immibis: that's a silly question. It's almost like asking why the window manager should decide where the windows go. All the window management stuff - including decorations to let the user manage the window - is the domain of the WM.
16:36 immibis: Some WMs use explicit window sizes and want resize borders. Others use tiling and don't want resize borders.
16:37 soreau: It's true, if the client freezes, then trying to get a menu via client (decoration) clicks or interact with decoration buttons is off the table
16:38 immibis: i currently don't have titles in my windows, and the active one has a red border; why should that be an application-specific setting instead of a window management setting?
16:38 ebassi_: It seems you have already decided, then, and you don't care about any other option
16:39 ebassi_: As a suggestion, I'd try to understand why other people have chosen differently, instead of saying that it's silly and stupid
16:40 immibis: it seems you are not interested in helping me to understand, so I'm putting you on /ignore
16:40 immibis: if you reply to this message, i won't see your reply
16:40 ebassi_: 🤷
16:42 psykose: is this just a reskinned theming debate again
16:42 vyivel: yes
16:44 soreau: just assert the compositor supports what you want or die with a shaming message otherwise
16:44 immibis: soreau: this does not sound conducive to a functioning software ecosystem
16:44 soreau: immibis: you can't possibly force all compositors to do what you expect
16:44 immibis: psykose: not sure what you mean - it's about window management widgets
16:44 soreau: there are no specs, this is FOSS
16:45 immibis: soreau: that is true. I can't force all X servers to display windows on the screen, I can't force all instances of /dev/null to not produce data when read, and I can't force all Linux kernels to have 'open' syscalls. But this is about things that people actually use, not the space of all possible broken things.
16:46 immibis: if half of people are actually using linux kernels without 'open' syscalls then maybe linux is not a nice platform to develop software for
16:47 q234rty: (having no decorations at all when SSD is not available is actually a viable option, since in GNOME the window could be controlled even if it doesn't have any decoration)
16:47 immibis: oh, how does the user control the window in that case?
16:47 soreau: there are plenty of ways
16:48 q234rty: I believe that would involve the use pressing the "super" key and dragging the window, right clicking, etc
16:49 soreau: Of course, the compositor has to be willing
16:49 soreau: your in the compositor's hands no matter what route you take
16:50 soreau: I can appreciate your point, but there's not much that can be done to fix every peice of software out there, claiming to be a compositor/wm/whatever
16:51 immibis: > But this is about things that people actually use, not the space of all possible broken things.
16:51 immibis: I understand these compositors are considered not broken
16:52 soreau: if the user chooses a broken-in-your-opinion compositor, how can you control this?
16:58 immibis: soreau: if you think Linux is broken, how can you control this so your users use Hurd?
17:00 soreau: I feel this conversation is growing more pointless with each message..
17:00 kennylevinsen: immibis: this has been discussed, at length, repeatedly over the last... Decade?
17:00 immibis: why hasn't it been resolved?
17:00 kennylevinsen: Please refer to existing discussions if you want this to be productive
17:02 immibis: where are they?
17:02 kennylevinsen: bugs are resolved, not feature and design requests. So far, consensus is NACK with GNOME being the primary non-ssd compositor.
17:03 kennylevinsen: wayland-devel and gitlab, google is your friend
17:03 kennylevinsen: There's probably a bible worth of prior discussions and conclusions at this point
17:03 immibis: hmm then i will have to NACK wayland if it has such serious unresolved issues. Tschüss
17:15 kennylevinsen:shrugs
21:56 wlb: weston Issue #810 opened by Link Mauve (linkmauve) Segfault when a graphics tablet is attached https://gitlab.freedesktop.org/wayland/weston/-/issues/810
22:13 wlb: weston Issue #811 opened by Link Mauve (linkmauve) Segfault when opening a program by pressing a stylus on a launcher https://gitlab.freedesktop.org/wayland/weston/-/issues/811