06:40MrCooper: zamundaaa[m]: re hangs when pushing to gitlab, have you changed the hostname to ssh.gitlab.freedesktop.org?
07:44nickdiego[m]: <jadahl> "nickdiego: mind doing that (file..." <- I think I've found out most of the answers (notes [here](https://notes.nickdiego.dev/chromium/pip-on-wayland)), though started the thread to discuss them with spec owners just in case: https://github.com/WICG/document-picture-in-picture/issues/136
09:13swick[m]: nickdiego: thanks a lot!
09:14swick[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
11:11zamundaaa[m]: MrCooper: ah, didn't notice that changed. Thanks!
13:01davidre: Now also emails...
13:12kennylevinsen: the person does identify themselves with a different name, but still suspicious...
13:13davidre: the content format of the two later emails feel very suspicious to me
13:38zzag: Yeah, it feels like something that could've been generated by an LLM
13:44wlb: weston Merge request !1535 closed (Draft: Scriptable shell with Lua)
13:56mclasen: 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.
13:57mclasen: but the only role for which anything is defined is pointer surfaces, from what I can find
14:02kennylevinsen: I imagine the intent of that phrase was just to allow/highlight wl_pointer's additional behavior for offset?
14:05kennylevinsen: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/346
14:06kennylevinsen: so the intent was also to point out that e.g., fullscreen toplevels might not have any behavior, but nothing further was indeed documented...
14:11mclasen: this came up in the context of center gravity for resizing centered windows
14:18kennylevinsen: you mean a toplevel that the compositor forcibly centers, but is being drag resized from the left or from the top?
14:19mclasen: a programmatic resize of a window that was centered initially
14:33kennylevinsen: and you want the client to maintain centering when this happens? yeah, it could use offset = size_delta / 2
14:34kennylevinsen: it'll only work if the compositor feels like it (not maximized, tiled, fullscreen, yadda yadda), but that's presumably fine
14:35mclasen: the client doesn't maintain anything, really
14:35mclasen: the question is whether the offset has implied semantics that the compositor ought to respect
14:35mclasen: but it seems that the answer is no
14:38WhyNotHugo: gitlab.fdo no uses recaptcha for login? Weird time to collect free AI training data for Google.
14:39kennylevinsen: 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
14:39swick[m]: mclasen: the client maintains it's center position by using offset = size_delta / 2
14:39mclasen: where does the spec say that ?
14:39swick[m]: right, the compositor just can ignore those things
14:39swick[m]: what part specifically?
14:39mclasen: "the client maintains its center position by using offset..."
14:40mclasen: semantics of offset with xdg-toplevels
14:40swick[m]: well, because wl_surface defines that behavior
14:40mclasen: that was my initial question
14:40swick[m]: the xdg_toplevel doesn't override the behavior, so the wl_surface behavior is in effect
14:40swick[m]: and I believe this should all work on mutter
14:42mclasen: I don't really read that out of the offset description, but ok
14:42mclasen: it talks about how the buffer is placed relative to the surface. Nothing about screen positions
14:43kennylevinsen: 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
14:43kennylevinsen: the wording is from wl_surface.attach's description of the x/y arguments
14:44swick[m]: the surface size and location is computed from the buffer basically
14:44kennylevinsen: the wording is a bit roundabout, I'll give you that
14:45swick[m]: tbh, that is all really weird and you can also move the window around with it
14:45kennylevinsen: yeah
14:45kennylevinsen: maybe the surface should just have been able to commit a gravity instead
14:45swick[m]: gravity would probably have been a btter choice
14:45swick[m]: yup
14:45kennylevinsen: +1 :D
14:46kennylevinsen: the reason it was moved out to wl_surface.offset was mainly because the inclusion in wl_surface.attach was bonkers
15:00daniels: 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
15:01daniels: (and also for being able to move windows before compositor-directed move)
16:44nickdiego[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
18:41swick[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.
18:43nickdiego[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)
18:44nickdiego[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)
18:45swick[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
18:46swick[m]: you could impose input limitations on both toplevel and pip roles
18:47swick[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)
19:01nickdiego[m]: <swick[m]> "right, but I think in the..." <- agreed
19:04nickdiego[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.
19:16kennylevinsen: android has non-video PIP, which works with navigation and meeting apps
19:18kennylevinsen: but if it's the w3c spec thing, then whether the browsers want to expose that much control is of course another story
19:18nickdiego[m]: kennylevinsen: I guess input is also handled by the platform still, right?
19:21nickdiego[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)
19:22nickdiego[m]: the other (and more recent) web spec is [document pip](https://github.com/steimelchrome/document-pip-explainer/blob/main/explainer.md), with which apps have more freedom to add arbitrary html content and handle input by themselves. That's currently supported only on desktop by now
19:23kennylevinsen: the android pip mode has you register actions with icons and stuff, but they can be arbitrary
19:23kennylevinsen: https://developer.android.com/develop/ui/views/picture-in-picture#add_controls
19:23kennylevinsen: there's an overview here: https://developer.android.com/design/ui/mobile/guides/home-screen/picture-in-picture
19:28zzag: this is user api though. how does android implement it under the hood?
19:34kennylevinsen: 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
19:34jadahl: the user api is the only thing interesting when comparing to android though, since the wayland protocol will as well be "user api"
19:34zzag: kennylevinsen: user api is what it is exposed to the users, it's expected to be restricted
19:35zzag: the platform may use more broader apis
19:36jadahl: 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
19:39zzag: speaking of controls, there are plenty of various controls, not just buttons, e.g. sliders, progress bars, popups, etc
19:39zzag: as a kwin dev, I'm not very keen about the idea of having all that complexity...
19:39kennylevinsen: 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.
19:39zzag: and speaking of android, I had plenty of cases when youtube app hanged and I couldn't get rid of the pip
19:39zzag: until I force stopped yt app
19:40zzag: so I suspect that parts of pip are implemented on client side
19:40kennylevinsen: I can attest to that also sometimes happening in wayland land
19:40kennylevinsen: not with a pip mind you
19:42kennylevinsen: The android actions are "just" an icon, a title, a description, and a "PendingIntent" (android ipc thingiemabbob)
19:43kennylevinsen: but it's certainly a lot more UI than we handle in e.g. sway
19:45nickdiego[m]: I don't get the point of using android as the main reference to define a desktop-driven (xdg) protocol extension
19:47nickdiego[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
19:47zzag: agreed
19:48kennylevinsen: 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
19:50jadahl: 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
19:51jadahl: e.g. providing picture-in-picture behavior is a goal, but providing always-on-top dialog windows is IMO a non-goal
19:52nickdiego[m]: I see, though some of those platforms, eg: android, have several constraints not necessarily applicable to desktop-driven UX. Example: heavy multitaking
19:52nickdiego[m]: multitasking*
19:53jadahl: not sure pip enables heavy multi tasking though, it's meant for a constant-in-your-face single task
19:55nickdiego[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?
19:55nickdiego[m]: jadahl: I meant desktop vs mobile
19:55jadahl: it would. could even be coupled with explicit user permission (also taking inspiration from android)
19:56jadahl: 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
19:58nickdiego[m]: jadahl: yeah, sounds reasonable
20:15jadahl: nickdiego[m]: regarding mitigations in your github issue: keyboard is important for screen reader users. no keyboard navigation means pip becomes unusable.
20:16jadahl: also what is "decorations enforced by the browser"? and I can't think of any decorations that a compositor would add
20:20nickdiego[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
20:21nickdiego[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
20:24nickdiego[m]: [this](https://groups.google.com/a/chromium.org/g/blink-dev/c/uK0hyACy_fg/m/JVXGUVylAAAJ) is the mail thread (there are more relevant links on [my notes](https://notes.nickdiego.dev/chromium/pip-on-wayland))
20:29jadahl: 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
20:32nickdiego[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
20:33nickdiego[m]: from a compositor perspective not sure how to enforce them (or if it makes sense)