10:25 whynothugo: Can I somehow drag from one client onto another, and have the receiving client receive a file, without creating the file on-disk?
10:25 whynothugo: I'm basically thinking of a winzip-like GUI where one would drag a file out.
10:34 pq: whynothugo, the Wayland interfaces were designed to allow e.g. passing pipe fd:s around and letting clients produce and consume the data on the fly.
10:35 pq: I'm not sure how that integrates with today's dnd mime types and stuff.
10:36 whynothugo: Right, piping the data via the fd is not an issue, the tricky part is the mime-type.
10:36 whynothugo: AFAIK, there's no mime type like "application/file; filename=photo.png".
10:36 emersion: the Wayland protocol carries the MIME type
10:37 emersion: but not sure file managers support something else than uri-list
10:37 whynothugo: An uri-list won't work because there's no URI for this data; it's data that the sender will decompress on the fly.
10:40 whynothugo: Actually, would using a mime-type "image/png; filename=photo.png" be valid? That _could_ hint to the receiver that the file being dragged should be saved with the given name.
10:43 emersion: no, this is not Content-Type
10:44 emersion: also filenames in Content-Type are not very standard, the RFC says to put it in the Content-Disposition
10:46 whynothugo: Ah, true.
10:46 whynothugo: So there's no way to implement this right now?
10:58 d_ed[m]: Not a standard way. Within KDE's winzip like UI we have a mimedata with a DBus service/path/token that the filemanager uses to callback into the winzip application to tell it where to extract a given set of files.
11:02 whynothugo: Interesting approach. Having the receiver tell the sender what to do with the files is potentially more efficient.
11:03 whynothugo: OTOH, this wouldn't work for dragging files fro the winzip-ui into an IM client.
11:05 d_ed[m]: yeah, then it falls back to the old path. It's not great.
11:05 d_ed[m]: You might also be interested in: https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.FileTransfer.xml
11:05 d_ed[m]: It's to solve the problem of dragging files between sandboxed apps where paths are different
11:06 d_ed[m]: I don't think it directly helps you, but it's a somewhat similar problem space
14:52 ahmadraniri[m]: Hello, for anyone who using latest wlroots and tinkering tinywl, how do you add popup unconstrain feature ?
15:09 kennylevinsen: ahmadraniri[m]: #wlroots was the right channel for this question - patience, my young padawan. :)
15:10 kennylevinsen: wlr_xdg_popup_unconstrain_from_box (rolls off the tongue) - see sway's popup_unconstrain for an example
16:12 dogukan: Hi! I am trying to see what DRM format modifiers are advertised by the dmabuf feedback protocol on Mutter 44.4 and Mesa 23.1.6 by running wayland-info and weston-simple-dmabuf-feedback applications on different AMD GPUs (I have a 6900XT and a 780M). However, I only get one modifier per format, and that modifier seems to be invalid (0x00ffffffffffffff). It seems like I get valid modifiers on other compositors like KWin and Weston. What could be
16:12 dogukan: happening here?
16:12 emersion: mutter blacklists modifiers on some vendors iirc
16:14 dogukan: Oh, that is interesting. Why does it do that?
16:18 MrCooper: long story :)
16:19 MrCooper: tl;dr: it was a workaround to allow direct scanout to work with older versions of Xwayland; the workaround is getting dropped in the upcoming mutter 45 release
16:22 dogukan: Hmm, so I assume I will be able to get valid format modifiers on mutter 45 and they won't be blacklisted. Is that correct?
16:24 MrCooper: yep
16:25 dogukan: Sounds good, thanks a lot for the help!
16:25 MrCooper: no worries! This makes me wonder if Fedora 39 has new enough Xwayland yet...
16:54 dogukan: Is there an issue or merge request that I could read more about this workaround? I tried to look up for it but couldn't find much
16:55 MrCooper: see https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2637
16:56 MrCooper: and https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3030 which dropped it again
17:06 dogukan: Thanks again!
19:37 ids1024: wp_security_context_v1 - "When both are set, the combination of the application ID and the sandbox engine must uniquely identify an application" - Does that mean sandbox_engine is optional? And if it isn't present, app_id/instance_id are allowed but have no defined meaning?
19:49 orowith2os[m]: ids1024: sounds like set_sandbox_engine *isn't* optional, if you're using this protocol?
19:49 orowith2os[m]: probably makes sense
19:50 orowith2os[m]: emersion might have more details
19:53 ids1024: "when both are set" implies either may not be set, so the wording should be clarified/fixed if the sandbox engine is required. Which might make sense. Though a security context with no sandbox engine could be useful just to communicate that clients connected through it should not have access to any sensitive protocols.
19:56 orowith2os[m]: ugh
19:57 orowith2os[m]: I'm trying to map out some concepts in Wayland to X11, both for a blog post and for a reverse-xwayland I'm going to miserably attempt
19:57 orowith2os[m]: and scaling is Fun™
19:58 orowith2os[m]: there's https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/733 for Xwayland, which gives out an actual scale factor, but I don't see anything else that's reliable
19:58 orowith2os[m]: (or even works for fractional scaling)
20:03 ids1024: I don't think there's ever been a good solution for fractional scaling on X. It's possible but problematic to round the scale factor up to an integer, and use randr to scale down to the scale you want. The fractional scaling protocol for Wayland is a recent addition.
20:03 orowith2os[m]: it's not just fractional scaling, but scaling as a whole
20:03 orowith2os[m]: it's all such a mess
20:06 orowith2os[m]: aaand of course the gnome gitlab is down, so I can't read the GDK docs and their implementation of the scale factor
20:27 orowith2os[m]: maybe I should just do this on top of SDL
20:27 orowith2os[m]: it would be easier
20:27 orowith2os[m]: and would probably make it easier to allow Wayland to run on other OSes too
20:39 ids1024: Building on top of SDL probably wouldn't allow wl_popup, drag and drop, layer-shell (if desired) and other such things to their X equivalents.
20:44 ids1024: Someone did start working on something like that for Wayland->Quartz, though it doesn't look like it got very far: https://github.com/owl-compositor/owl
20:45 orowith2os[m]: ids1024: bah, I can access X directly if necessary
20:58 orowith2os[m]: okay, so it looks like there's just no concept of a scale factor in C.
20:58 orowith2os[m]: *x
20:58 orowith2os[m]: *X
20:58 orowith2os[m]: at all.
20:58 orowith2os[m]: it's all hacks.
20:58 orowith2os[m]: and not all of them work.
21:02 ids1024: "it's all hacks and not all of them work" - perhaps that could be the official motto of X.org. That's basically what all (well, a lot) of modern X11 is. Which is essentially why Wayland exists.
21:03 orowith2os[m]: I will unironically add that to the documentation and web page of X after I post this
21:23 kennylevinsen: orowith2os[m]: just skip scaling to begin with, it's not important for a demonstration
21:24 kennylevinsen: later you could hack it by turning the gross font dpi thing into a fractional scale value or something - X11 is a hack, so what you make will in turn also be a hack.
21:25 kennylevinsen: No point in fretting over that :)