ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
calcul0n has joined #wayland
calcul0n has quit [Ping timeout: 480 seconds]
calcul0n has joined #wayland
calcul0n has quit [Ping timeout: 480 seconds]
cptaffe has joined #wayland
Flat_ has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
Company has joined #wayland
Flat has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
yrlf has quit [Ping timeout: 480 seconds]
yrlf has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Company has quit [Quit: Leaving]
nerdopolis has quit [Ping timeout: 480 seconds]
feaneron_ has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
riteo has quit [Ping timeout: 480 seconds]
sima has joined #wayland
glennk has joined #wayland
tzimmermann has joined #wayland
coldfeet has joined #wayland
riteo has joined #wayland
calcul0n has joined #wayland
coldfeet has quit [Quit: Lost terminal]
kts has joined #wayland
<MrCooper>
zamundaaa[m]: re hangs when pushing to gitlab, have you changed the hostname to ssh.gitlab.freedesktop.org?
<swick[m]>
I think the main motivation for not-a-toplevel pip not necessarily security but increased control by the compositor, and the freedom to build UI/UX differently than toplevels
calcul0n has quit [Ping timeout: 480 seconds]
ity is now known as Guest13232
ity has joined #wayland
Guest13232 has quit [Remote host closed the connection]
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
Hypfer has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
MrCooper: ah, didn't notice that changed. Thanks!
leonanavi has joined #wayland
leon-anavi has quit [Read error: No route to host]
Hypfer has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
ahartmetz has joined #wayland
nerdopolis has joined #wayland
mclasen has joined #wayland
FreeFull_ has joined #wayland
FreeFull has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
kts has joined #wayland
funderscore is now known as f_
<davidre>
Now also emails...
karenw has joined #wayland
<kennylevinsen>
the person does identify themselves with a different name, but still suspicious...
<davidre>
the content format of the two later emails feel very suspicious to me
FreeFull_ has quit []
feaneron has joined #wayland
Company has joined #wayland
bindu has quit [Remote host closed the connection]
<zzag>
Yeah, it feels like something that could've been generated by an LLM
<mclasen>
the wl_surface.offset docs say: The exact semantics of wl_surface.offset are role-specific. Refer to the documentation of specific roles for more information.
<mclasen>
but the only role for which anything is defined is pointer surfaces, from what I can find
<kennylevinsen>
I imagine the intent of that phrase was just to allow/highlight wl_pointer's additional behavior for offset?
<kennylevinsen>
so the intent was also to point out that e.g., fullscreen toplevels might not have any behavior, but nothing further was indeed documented...
<mclasen>
this came up in the context of center gravity for resizing centered windows
<kennylevinsen>
you mean a toplevel that the compositor forcibly centers, but is being drag resized from the left or from the top?
<mclasen>
a programmatic resize of a window that was centered initially
karenw has quit [Ping timeout: 480 seconds]
<kennylevinsen>
and you want the client to maintain centering when this happens? yeah, it could use offset = size_delta / 2
rgallaispou has joined #wayland
<kennylevinsen>
it'll only work if the compositor feels like it (not maximized, tiled, fullscreen, yadda yadda), but that's presumably fine
<mclasen>
the client doesn't maintain anything, really
<mclasen>
the question is whether the offset has implied semantics that the compositor ought to respect
<mclasen>
but it seems that the answer is no
<WhyNotHugo>
gitlab.fdo no uses recaptcha for login? Weird time to collect free AI training data for Google.
<kennylevinsen>
mclasen: should be fine - the compositor can always reposition a window, and ignoring offset for a toplevel is the same as immediately repositioning it by that amount
<swick[m]>
mclasen: the client maintains it's center position by using offset = size_delta / 2
<mclasen>
where does the spec say that ?
<swick[m]>
right, the compositor just can ignore those things
<swick[m]>
what part specifically?
<mclasen>
"the client maintains its center position by using offset..."
<mclasen>
semantics of offset with xdg-toplevels
<swick[m]>
well, because wl_surface defines that behavior
<mclasen>
that was my initial question
<swick[m]>
the xdg_toplevel doesn't override the behavior, so the wl_surface behavior is in effect
<swick[m]>
and I believe this should all work on mutter
<mclasen>
I don't really read that out of the offset description, but ok
<mclasen>
it talks about how the buffer is placed relative to the surface. Nothing about screen positions
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #wayland
<kennylevinsen>
It tries to describe that the surface is moved, shifting the buffer's upper left corner by the specified value, which is in surface-local coordinates
<kennylevinsen>
the wording is from wl_surface.attach's description of the x/y arguments
<swick[m]>
the surface size and location is computed from the buffer basically
<kennylevinsen>
the wording is a bit roundabout, I'll give you that
<swick[m]>
tbh, that is all really weird and you can also move the window around with it
<kennylevinsen>
yeah
<kennylevinsen>
maybe the surface should just have been able to commit a gravity instead
<swick[m]>
gravity would probably have been a btter choice
<swick[m]>
yup
<kennylevinsen>
+1 :D
<kennylevinsen>
the reason it was moved out to wl_surface.offset was mainly because the inclusion in wl_surface.attach was bonkers
kts has joined #wayland
<daniels>
the historical yak shave is dx/dy were defined as part of wl_egl_window_resize() in the bad old days when wl_surface.attach was the thing which did the thing, because we didn't yet have wl_surface.commit
yrlf has quit [Quit: Ping timeout (120 seconds)]
<daniels>
(and also for being able to move windows before compositor-directed move)
yrlf has joined #wayland
rgallaispou has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
exxxxkc has joined #wayland
tzimmermann has quit [Quit: Leaving]
kts has joined #wayland
kts has quit []
kts has joined #wayland
Flat has quit [Quit: Rip internet]
kts has quit [Quit: Konversation terminated!]
Flat has joined #wayland
<nickdiego[m]>
<swick[m]> "I think the main motivation..." <- assuming by "not-a-toplevel pip" you mean the approach 2 I mention there, how different UI/UX could be implemented with it that wouldn't be possible with the other approach? I thought the main difference would be input handing
tokyo4j_ has joined #wayland
glennk has quit [Read error: Connection reset by peer]
glennk has joined #wayland
tokyo4j has quit [Ping timeout: 480 seconds]
tokyo4j_ is now known as tokyo4j
leonanavi has quit [Quit: Leaving]
mclasen has quit [Ping timeout: 480 seconds]
kts has joined #wayland
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #wayland
kts has quit [Quit: Konversation terminated!]
crazybyte4 has quit [Read error: Connection reset by peer]
kts has joined #wayland
ahartmetz has quit [Ping timeout: 480 seconds]
<swick[m]>
nickdiego: a toplevel is a normal window, but to get something like on iOS and Android, this doesn't really work. for example, a toplevel in GNOME Shell will be part of the expose-style overview, while a PiP window should probably stick stay at the same position without changing.
<nickdiego[m]>
swick[m]: ah, right, when I mention toplevel there, it's not literally a toplevel, it'd be a toplevel-like window with special rules (including always on top, bypass-window-switcher ui, etc)
<nickdiego[m]>
more like a toplevel in the sense that clients would be able to render arbtrary content to it (required by that web API) and handle input on it (probably in a limited way)
<swick[m]>
right, but I think in the context of wayland we should try to separate the ideas: toplevel vs pip surface roles, and input handling
<swick[m]>
you could impose input limitations on both toplevel and pip roles
<swick[m]>
the current proposal boils down to toplevel role with always-on-top (which btw, in mutter still means it becomes part of the expose)
mclasen has joined #wayland
<nickdiego[m]>
<swick[m]> "right, but I think in the..." <- agreed
<nickdiego[m]>
btw the answer to your question 'how is that spec supposed to be implemented in iOS?' seems to be "it won't" and probably neither in android as none of them (currently) support non-video pip apis at platform lever. Also, it seems Apple stated explicitly they'd not support it.
sima has quit [Ping timeout: 480 seconds]
<kennylevinsen>
android has non-video PIP, which works with navigation and meeting apps
f_ is now known as Guest13267
<kennylevinsen>
but if it's the w3c spec thing, then whether the browsers want to expose that much control is of course another story
<nickdiego[m]>
kennylevinsen: I guess input is also handled by the platform still, right?
<nickdiego[m]>
even with the supposedly [video-only web spec](https://github.com/w3c/picture-in-picture/blob/main/explainer.md) it's possible to render arbitrary content using a canvas element, though in that case input is limited to a predefined list of actions/buttons and handled by the platform (or browser)
<zzag>
this is user api though. how does android implement it under the hood?
<kennylevinsen>
what do you mean? the user API is what one has to work with, and making a floating surface isn't really technically interesting on its own
<jadahl>
the user api is the only thing interesting when comparing to android though, since the wayland protocol will as well be "user api"
<zzag>
kennylevinsen: user api is what it is exposed to the users, it's expected to be restricted
<zzag>
the platform may use more broader apis
<jadahl>
what apps can do is what is relevant here. an android app, e.g. a web browser, can't implement the proposed w3c spec with just actions and icons, if I understand the Android API correctly
<zzag>
speaking of controls, there are plenty of various controls, not just buttons, e.g. sliders, progress bars, popups, etc
<zzag>
as a kwin dev, I'm not very keen about the idea of having all that complexity...
<kennylevinsen>
zzag: what you might be able to get Android to do if you break the rules and make an unpublishable app isn't really interesting. The user API is the contract you have to adhere to.
<zzag>
and speaking of android, I had plenty of cases when youtube app hanged and I couldn't get rid of the pip
<zzag>
until I force stopped yt app
<zzag>
so I suspect that parts of pip are implemented on client side
<kennylevinsen>
I can attest to that also sometimes happening in wayland land
<kennylevinsen>
not with a pip mind you
<kennylevinsen>
The android actions are "just" an icon, a title, a description, and a "PendingIntent" (android ipc thingiemabbob)
<kennylevinsen>
but it's certainly a lot more UI than we handle in e.g. sway
<nickdiego[m]>
I don't get the point of using android as the main reference to define a desktop-driven (xdg) protocol extension
<nickdiego[m]>
it'd be more plausible, though, if we were talking about a more specific scenario, eg: a protocol extension for IVI domain for example
<zzag>
agreed
<kennylevinsen>
the point isn't to use android as main reference, but to look at platforms where PIP is prevalent to understand what users expect and may need
<jadahl>
nickdiego[m]: it more taking inspiration from how mobile platforms to some degree try harder to achieve non-intrusive behaviour (with various degrees of success) by providing windowing system building blocks in a different way than X11 / windows
<jadahl>
e.g. providing picture-in-picture behavior is a goal, but providing always-on-top dialog windows is IMO a non-goal
<nickdiego[m]>
I see, though some of those platforms, eg: android, have several constraints not necessarily applicable to desktop-driven UX. Example: heavy multitaking
<nickdiego[m]>
multitasking*
kts has quit [Quit: Konversation terminated!]
<jadahl>
not sure pip enables heavy multi tasking though, it's meant for a constant-in-your-face single task
rasterman has quit [Quit: Gettin' stinky!]
<nickdiego[m]>
Enforcing constraints (such as, size, positions, activation, user permissions, decorations, singleton) at compositor-side would already make them quite distant from always-on-top dialogs, wouldn't it?
<nickdiego[m]>
jadahl: I meant desktop vs mobile
<jadahl>
it would. could even be coupled with explicit user permission (also taking inspiration from android)
<jadahl>
e.g. to let an app do pip, one have to go and enable "show window on top of other apps [x]" in the system settings for the app
<nickdiego[m]>
jadahl: yeah, sounds reasonable
f_ has quit [Killed (NickServ (This nickname is registered and protected))]
f_ has joined #wayland
<jadahl>
nickdiego[m]: regarding mitigations in your github issue: keyboard is important for screen reader users. no keyboard navigation means pip becomes unusable.
Brainium has joined #wayland
<jadahl>
also what is "decorations enforced by the browser"? and I can't think of any decorations that a compositor would add
<nickdiego[m]>
<jadahl> "nickdiego: regarding mitigations..." <- those items come from a mail thread where the web api was first proposed for impl, someone (from security area) suggested a few mitigations IIUC, so I was trying to confirm which of them were actually implemented
<nickdiego[m]>
decoration: that was about one of the concerns, "UI inpersonation" iirc, them it was suggested to have a window decoration which would make it possible to differentiate it from system UI for example
<jadahl>
not sure people would understand why it'd have a specific frame around it that isn't seen on anything else, but I'm no designer or UX researcher
<nickdiego[m]>
yeah, from the browser perspective, the set of mitigations might make sense, eg: drop shadows, frame, origin url explicit somewhere in the window, etc. Also, it's not (necessarily) a "frame not seen on anything else", but at least some indicaton, eg: drop shadows
<nickdiego[m]>
from a compositor perspective not sure how to enforce them (or if it makes sense)
sima has joined #wayland
sima has quit [Ping timeout: 480 seconds]
brosna has quit [Quit: May your keyboard never stick and your mouse always click]
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
bindu_ has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
brosna has joined #wayland
garnacho has quit [Remote host closed the connection]
kestrel has quit [Read error: Connection reset by peer]
kestrel has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
RAOF has quit [Read error: Connection reset by peer]