ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
nerdopolis has joined #wayland
nerdopolis has quit [Remote host closed the connection]
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
PuercoPop has joined #wayland
nerdopolis has joined #wayland
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
PuercoPop has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
bonecchi has joined #wayland
<bonecchi>
Hello everyone
<bonecchi>
Is background blur not possible as of now on wayland? Can't find any info portraying to that
<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
<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)
<orowith2os[m]>
not sure how much the last bit holds up
<bonecchi>
so basically every client needs to develop a solution for this
<orowith2os[m]>
not really
<orowith2os[m]>
they don't need to do anything
<orowith2os[m]>
and first up, a blur protocol or smth needs to be available in Wayland
<orowith2os[m]>
(which did have a proposal somewhere)
<ammen99[m]>
bonecchi: every wayland compositor has to develop a solution, see for example hyprland, wayfire and some sway forks which have blur
<ammen99[m]>
a blur protocol would only help if you want to blur parts of a window
<orowith2os[m]>
the initial use case for blur that I would have would be simulating Mica
<orowith2os[m]>
it would allow apps to do blur themselves, which is more what we'd (Inochi2D/libsoba) would want here
<orowith2os[m]>
but there's still the issue of security
<bonecchi>
that's why I'm asking, wouldn't the nature of wayland make this impossible
<orowith2os[m]>
there's always the possibility of just telling the compositor what the app wants, but that would be really nasty....
<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
<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?
<orowith2os[m]>
yep
<davidre>
But that's desired in that design Case you are looking at iiuc?
<orowith2os[m]>
window contents aren't an interest, but the user background could contain private info (photos), which is what I'm worried about
<davidre>
Got it!
<davidre>
With a general compositor does blur protocol of course your compositor could just do that as well if you are worried
* dottedmag
wonders if anyone writes down their passwords on the background picture
<davidre>
I can imagine on Plasma writing them into note taking applets on the desktop :D
<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
<orowith2os[m]>
(client telling the compositor what to do)
<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
<davidre>
I was thinking Client says region x is blurred. Your compositor would do desktop image thing, KWin would do the blur like now.
<davidre>
Ah ok that's not desireable for clients maybe to much variance in appearance
<orowith2os[m]>
mhm
<orowith2os[m]>
that's why the issue is about grabbing the desktop image, not letting the compositor handle it
<davidre>
I think there's a portal to set the desktop image
<orowith2os[m]>
but ideally we would be able to do this all smoothly
<orowith2os[m]>
using a portal for this goes quite a bit against that
<orowith2os[m]>
also, we want to be able to get just what's below the current window
<orowith2os[m]>
not the entire thing
<dottedmag>
Does it make any difference, security-wise?
<orowith2os[m]>
and we need to do so a lot (resizing, moving, etc)
<orowith2os[m]>
what does?
<dottedmag>
grabbing only a part under the current windo
<dottedmag>
*w
<orowith2os[m]>
not much, but it helps
<orowith2os[m]>
I'd like some thoughts on this from jadahl and emersion, Jonas being the person here I'm familiar with the most
<kennylevinsen>
Wallpaper is not a fixed entity - there might be none, it might be animated 3D graphics, it might be an ever changing image...
<kennylevinsen>
And transparency without window content looks really weird. I recall some terminal emulators implementing this a decade ago.
<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
<orowith2os[m]>
transparency on its own is already handled, IIRC?
<kennylevinsen>
The frosted glass effect (both windows and mac style) require the compositor to make a special blurring pass
<orowith2os[m]>
IIRC on Windows it's handled client-side, but I didn't look too much into it, so could be wrong
<kennylevinsen>
Opaque region is an optimization, all windows allow transparency by default when a pixels alpha value is less than 100%
<orowith2os[m]>
noted
<orowith2os[m]>
also, ah, just grabbing one portion of the background at a time might not be the best
<orowith2os[m]>
"Mica is specifically designed for app performance as it only samples the desktop wallpaper once to create its visualization."
<orowith2os[m]>
so the windows would need to know where they are in relation to the background
<orowith2os[m]>
as well as access to the full background itself
<orowith2os[m]>
I think this is the time where I nope out
<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")
<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
<kennylevinsen>
Whether to reveal it as a screenshot to the client wanting to blur or to perform the blur itself
<orowith2os[m]>
kennylevinsen: not a fully composited desktop, but access to the background image and window position
sevz has quit [Quit: WeeChat 4.0.4]
<orowith2os[m]>
the client can figure it out from there
<orowith2os[m]>
(also, not sure what "blue target" is)
<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...
<kennylevinsen>
and well that would also only work for mica
<orowith2os[m]>
yeah, pretty niche use case
<kennylevinsen>
Everyone else to my knowledge expect proper frosted glass
<kennylevinsen>
Ah I just remembered the worst part of client-side transparency - synchronization
<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
<kennylevinsen>
I guess a blur protocol could have a mica "wallpaper only" mode to do this effect correctly without all the negatives...
<soreau>
at best, the protocol will not be supported by compositors because it will just make a mess of the code and the desktop
<soreau>
it doesn't really make sense to have client control for this feature IMO
<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
<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 :/
dcz_ has joined #wayland
bbhtt has quit [Ping timeout: 480 seconds]
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
lsd|2 has quit []
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
mblenc1 has quit [Read error: Connection reset by peer]
kelnos has quit [Remote host closed the connection]
kelnos has joined #wayland
bonecchi has quit [Remote host closed the connection]
mblenc has joined #wayland
Company has joined #wayland
<jadahl>
the discussion about client side "transparency" (reading the X11 root window content) and laggyness reminds me of running Eterm around the year 2000
<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
iomari891 has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc1 has quit [Ping timeout: 480 seconds]
<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 :(
junaid has quit [Remote host closed the connection]
heapify has joined #wayland
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
fmuellner has joined #wayland
heapify has quit [Quit: heapify]
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
tanty has quit [Quit: Ciao!]
tanty has joined #wayland
tanty has quit [Quit: Ciao!]
junaid has joined #wayland
tanty has joined #wayland
nerdopolis has joined #wayland
iomari891 has quit [Read error: No route to host]
iomari891 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
bbhtt has joined #wayland
nerdopolis has joined #wayland
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
rederick29 has joined #wayland
vbt has quit [Remote host closed the connection]
vbt has joined #wayland
Guest1043 is now known as raghavgururajan
jmdaemon has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
iomari892 has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
<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?
<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
<immibis>
but I've read that almost no compositors support SSD
<soreau>
Use a compositor that does?
<kennylevinsen>
Many servers support SSD's, but use libdecor if you want decoration without thinking about it
ohmltb^ has quit [Remote host closed the connection]
ohmltb^ has joined #wayland
utsweetyfish has quit [Remote host closed the connection]
<immibis>
soreau: you think i get to decide which compositor my users use?
<soreau>
on the client side, you can probably fall back to CSD if the compositor doesn't support the decoration protocol or SSD
ohmltb^ has quit [Remote host closed the connection]
<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
ohmltb^ has joined #wayland
junaid has joined #wayland
<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.
<boud>
(Because the user didn't cancel the suspend.)
<boud>
It's pointless alerting the user that s/he didn't prevent his/her mobile phone from suspending to save power.
<boud>
Sorry - wrong channel! ignore my last three lines.
<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)
<immibis>
this is actually a stupider situation than in X11
<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?
<psykose>
it's the same shit both ways
<immibis>
that too!
<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?
junaid has quit [Ping timeout: 480 seconds]
<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.
<immibis>
Some WMs use explicit window sizes and want resize borders. Others use tiling and don't want resize borders.
<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
<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?
<ebassi_>
It seems you have already decided, then, and you don't care about any other option
<ebassi_>
As a suggestion, I'd try to understand why other people have chosen differently, instead of saying that it's silly and stupid
<immibis>
it seems you are not interested in helping me to understand, so I'm putting you on /ignore
<immibis>
if you reply to this message, i won't see your reply
<ebassi_>
🤷
<psykose>
is this just a reskinned theming debate again
<vyivel>
yes
<soreau>
just assert the compositor supports what you want or die with a shaming message otherwise
<immibis>
soreau: this does not sound conducive to a functioning software ecosystem
<soreau>
immibis: you can't possibly force all compositors to do what you expect
<immibis>
psykose: not sure what you mean - it's about window management widgets
<soreau>
there are no specs, this is FOSS
<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.
<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
<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)
vyivel has left #wayland [#wayland]
<immibis>
oh, how does the user control the window in that case?
<soreau>
there are plenty of ways
<q234rty>
I believe that would involve the use pressing the "super" key and dragging the window, right clicking, etc
<soreau>
Of course, the compositor has to be willing
<soreau>
your in the compositor's hands no matter what route you take
<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
<immibis>
> But this is about things that people actually use, not the space of all possible broken things.
<immibis>
I understand these compositors are considered not broken
<soreau>
if the user chooses a broken-in-your-opinion compositor, how can you control this?
<immibis>
soreau: if you think Linux is broken, how can you control this so your users use Hurd?
<soreau>
I feel this conversation is growing more pointless with each message..
<kennylevinsen>
immibis: this has been discussed, at length, repeatedly over the last... Decade?
<immibis>
why hasn't it been resolved?
<kennylevinsen>
Please refer to existing discussions if you want this to be productive
<immibis>
where are they?
<kennylevinsen>
bugs are resolved, not feature and design requests. So far, consensus is NACK with GNOME being the primary non-ssd compositor.
<kennylevinsen>
wayland-devel and gitlab, google is your friend
<kennylevinsen>
There's probably a bible worth of prior discussions and conclusions at this point
<immibis>
hmm then i will have to NACK wayland if it has such serious unresolved issues. Tschüss