07:01emersion: > wl_coffee_machine
07:01emersion: can't wait to get that in w-p!
07:09jadahl: should be xdg_coffee_machine I guess, but why not
07:09zzag: then nobody will have coffee
07:09jadahl: xdg_coffee_esperesso, xdg_coffee_french_press, xdg_coffee_filter
07:09zzag:runs away
07:10jadahl: a tea extension to the coffee shell would help?
07:10jadahl: a bit calcified tea
07:15emersion: tea is a subset of coffee now? :/
07:16emersion:sees his pu-erh make waves as a sign of protest
07:16zzag: heh, with my tea and coffee drinking habits, I'm actually worried about kidney stones
07:18zzag: just in case, citric acid cleans calcium buildup in kettles very well
07:18jadahl: emersion: in coffee machines it seems common :(
07:18xhivo97: would more water help with that lol, I switched to caffeine tablets because as much as I love coffee my stomach doesn't
07:18jadahl: hot water with a teste of calcium from the coffee
07:19xhivo97: I don't use kettles anymore after I saw chunks of calcium floating inside
07:19jadahl:does coffee in the morning, and tea in the afternoon
07:20xhivo97: How should I do software rendering for a game in wayland? I need a way to tell the compositor to render when the buffer is ready? How to do that without added frames in latency? I want the game to have a target FPS and try to run at that and update as fast as it can to the compositor
07:21jadahl: I was at a "tea maker" once where one could wipe the outside of the tea fermentation machine thing with your finger to get a caffeeine directly from the source
07:21emersion: ahah
07:22jadahl: the more fermentation, the more caffeine stuck to the metallic fermentation .. oven thing?
07:22jadahl: xhivo97: allocate an shm buffer, write pixels to it, attach and commit to a surface
07:24xhivo97: How often should I do that is there a way to sync it? I have an shm buffer I am drawing to it's just the game FPS vs compositor drawing FPS being separate that confuses me as I kind of whant the render loop to run on it's own (probably on same thread for now)
07:24xhivo97: I guess my question is, can I commit faster than the cserver can update?
07:25emersion: you can, but it's wasteful
07:25emersion: this will result in work (drawing frames) which will be unused (superseded by a more recent frame)
07:25xhivo97: Wouln't ot potentially improve latency? Esp if I manage to do input handling at higher rates too?
07:26emersion: the proper way to improve latency is to try to draw and commit a bit before vsync
07:26emersion: but with shm, things are slow anyways
07:26rosefromthedead: although i'm not sure game devs have got the memo yet
07:27emersion: performance and shm, pick one :P
07:29jadahl: we need a "use nearest" scaling extension so shm pixel graphics clients can create 480x320 buffers and scale up with viewporter
07:29xhivo97: I am a beginner in all this (def not a game dev, I wish lol) that's why I am starting with shm and not using the GPU this early I want to understand how rendering works, but I think if I think about stuff like latency I'll get sidetracked and not learn what I really neeed to learn probably
07:30emersion: jadahl: i think i have a branch with that somewhere…
07:30emersion: (KMS has a prop for it)
07:30emersion: xhivo97: this stuff is definitely a more advanced topic
07:31kennylevinsen: xhivo97: just clean or descale your kettle if it's that bad lol
07:32rosefromthedead: is shm still slow if there's not much damage?
07:32xhivo97: Tell that to my dad, he uses it and looks like he'd rather suffer through the pain of another kidney stone than clean it lol
07:32emersion: rosefromthedead: games usually don't do damage tracking
07:32rosefromthedead: i see people saying if you want any perf at all then avoid it but foot proudly talks about using shm right at the top of the performance page lol
07:33rosefromthedead: yeah im thinking about regular apps now
07:33kennylevinsen: It's faster with less damage, but it always requires slow pixel copy to a dmabuf
07:34emersion: it will never be faster than uploading font glyths to the GPU once at startup and then texturing them
07:34rosefromthedead: right, i guess what im really looking for is "do the relevant apis allow you to only copy the damaged part" which it seems like they do?
07:34kennylevinsen: Yes
07:34emersion: yes, damage tracking does help
07:34rosefromthedead: cool
07:34xhivo97: Is that copy something that is always there for software rendering or is it specific to wayland?
07:35kennylevinsen: always true
07:35rosefromthedead: i can put off learning enough gl/vk to render text for a little longer then :P
07:35emersion: the copy is always there when shm is used and the computer has a GPU (internal or external)
07:36emersion: yeah, proper font rendering on GPUs… sounds like a real pain for sure
07:36rosefromthedead: it's basically just blitting, how hard could it be...
07:36rosefromthedead:was never seen again
07:36emersion: lol
07:37JEEB: emersion: yup. reminds me of someone having ideas of implementing something like that for the libass subtitle renderer, but that never went anywhere.
07:37emersion: famous last words
07:37emersion: oof, .ass gpu rendering
07:37emersion: that sounds fun
07:37xhivo97: i was curous about font rendering and concluded it's not an excersise I can do at my level it looks really hard. Whoever came up with .ass deserves a medal
07:38JEEB: IIRC .ass was come up based on .ssa in a week or so (design during the work week, then hacking on the week-end for implementation)
07:38kennylevinsen: fast forward to interchangeably right-to-left, left-to-right, top-to-bottom arabic-chinese-emoji text
07:38rosefromthedead: i've learned that even if you defer as much work as possible to libraries, font rendering *still* manages to be a huge pain
07:38JEEB: also it left a lot of stuff unspecified which ended up just being referenced to GDI/the initial implementation
07:38JEEB: which seems to have been quite a PITA
07:39JEEB: esp. when the ye olde reference implementation starts seeming like a bug
07:40JEEB: I think jfs tried to define a better-defined multi-profile thing in the 2010s but that didn't go much anywhere
07:40JEEB: rosefromthedead: yea, that's my experience as well looking from the side lines
07:41JEEB: even with freetype2, harfbuzz, fribidi etc handling things for you
08:10emersion: jadahl: by any chance, any progress on the flatpak stuff? would be nice to be able to release a new w-p
08:17wlb: wayland-protocols Issue #59 closed \o/ (linux-dmabuf: figure out a good way to broadcast set of supported formats/modifiers https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/59)
08:18wlb: wayland-protocols Merge request !223 opened by Simon Ser (emersion) linux-dmabuf: mark as stable https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/223
08:20orowith2os: It's funny how I ended up causing so much chaos over this with one simple patch update, lol
08:21orowith2os: Well, at least now that's all fixed up :)
08:22orowith2os: eventually I'll get to writing a compositor myself (definitely), so I don't have to keep asking around and bugging yall :P
08:23jadahl: emersion: smcv wanted alex to look again since he started. nagged alexl internally (he is at another dept at rh) but hasn't replied
08:24wlb: wayland-protocols Merge request !224 opened by Simon Ser (emersion) linux-dmabuf: require all planes to use the same modifier https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/224
08:25jadahl: emersion: will try again
08:25emersion: ty
08:36wlb: wayland-protocols Merge request !225 opened by Simon Ser (emersion) readme: reword intro for backward incompatible change section https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/225
08:39wlb: wayland-protocols Merge request !226 opened by Simon Ser (emersion) readme: version should be included in stable protocol filenames https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/226
08:40emersion: </patches>
09:12wlb: wayland-protocols Merge request !201 merged \o/ (xdg-shell: Add suspended toplevel state https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/201)
09:12wlb: wayland-protocols/main: Daniel Stone * xdg-shell: Add suspended toplevel state https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/c124b641b346 stable/xdg-shell/xdg-shell.xml
09:14wlb: wayland-protocols/main: Simon Ser * security-context-v1: new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/12c063088e97 staging/security-context/README staging/security-context/engines.md staging/security-context/security-context-v1.xml meson.build
09:14wlb: wayland-protocols Merge request !68 merged \o/ (security-context: new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68)
09:17wlb: wayland-protocols/main: David Redondo * xdg-activation: Clarify that the token stays valid if the object is destroyed https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/3c1fb30817dc staging/xdg-activation/xdg-activation-v1.xml
09:17wlb: wayland-protocols Merge request !214 merged \o/ (xdg-activation: Clarify that the token stays valid if the object is destroyed https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/214)
09:18wlb: wayland-protocols/main: Kirill Chibisov * stable/xdg-shell: clarify initial wl_surface acknowledgement https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/174b3487a2ac stable/xdg-shell/xdg-shell.xml
09:18wlb: wayland-protocols Merge request !213 merged \o/ (stable/xdg-shell: clarify initial wl_surface acknowledgement https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/213)
09:18jadahl: merge fest
09:18jadahl: and its only monday
09:20emersion: i think that's everything which was ready
09:21jadahl: i'll spin a release then
09:22emersion: sweet
09:22jadahl: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/226 and https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/225 seems uncontroversial enough too
09:22jadahl: one is just better wording for the same thing and the other is obviously what we weed to do
09:23emersion: feel free to merge, but since they're just README updates, i'm not in a hurry to push them
09:24emersion: (people usually look at READMEs from the GitLab page, not the release tarball)
09:25jadahl: alright, lets not delay things
10:03wlb: wayland-protocols Merge request !227 opened by Jonas Ådahl (jadahl) build: Bump version to 1.32 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/227
10:04wlb: wayland-protocols/main: Jonas Ådahl * build: Bump version to 1.32 https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/681c33c8547d meson.build
10:04wlb: wayland-protocols Merge request !227 merged \o/ (build: Bump version to 1.32 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/227)
10:04wlb: wayland-protocols New tag: 1.32 https://gitlab.freedesktop.org/wayland/wayland-protocols/tags/1.32
10:05emersion: thanks!
10:06jadahl: seems my glab is old
10:12jadahl: there we go
10:15llyyr: nice
10:33wlb: wayland.freedesktop.org Merge request !59 opened by Jonas Ådahl (jadahl) releases: Add wayland-protocols 1.32 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/59
10:33wlb: wayland.freedesktop.org Merge request !59 merged \o/ (releases: Add wayland-protocols 1.32 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/59)
10:33wlb: wayland.freedesktop.org/main: Jonas Ådahl * releases: Add wayland-protocols 1.32 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/cb30e2d47198 releases.html
10:44emersion: at some point maybe we should just link to the GitLab release page
10:44emersion: instead of manually massaging the HTML each release
10:45jadahl: what the gitlab release page is missing is the announcement
10:45vyivel: how does one massage the html
10:45jadahl: link to announcement
10:46emersion: hm, true
10:46jadahl: vyivel: with the right kind of oil
10:46emersion: and GitLab releases are a but finicky: when editing them sometimes they loose the assets
10:46emersion: bit*
10:47jadahl: that sounds scary
10:47emersion: it is :<
10:55pq: kchibisov, what do you mean there are only downsides to doing decorations+app in the same surface? That's the ideal choice. No, you don't need to redraw everything to highlight a decor button, you track damage.
10:56kchibisov: I think I'm just used to hw accelerated rendering here.
10:57kchibisov: Or there're cases where you pass everything to e.g. skia.
11:10pq: kchibisov, right, there is even https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_swap_buffers_with_damage.txt
11:10kchibisov: But it has nothing to do with how much you draw?
11:10kchibisov: you need buffer age.
11:10pq: yes, buffer_age is the other part
11:11pq: but without swap_buffers_with_damage, the compositor does too much work
11:11pq: it all exists if anyone just cares to use it
11:11kchibisov: I'm just saying that subsurfaces are way easy to set things up.
11:12pq: guess I just disagree
11:12kchibisov: I guess, I was just doing subsurfaces for decorations for a long time.
11:13kchibisov: The only issue is that compositors tend to break with them.
11:13pq: sub-surface seams have a risk of showing
11:15kchibisov: But if compositor can at least follow what subsurfaces expect it should be all good, given that you have sync/desync behavior.
11:15pq: compositor bugs and bugs, but even without those I wouldn't use sub-surfaces unless parts of the window may benefit performance by being on different buffers.
11:15pq: *are bugs
11:15kchibisov: I'd assume you're talking about video players.
11:16pq: yes, those are a prime example, since the buffer from a hw decoder might be able to shown on KMS, or at least you can avoid one GPU blit per frame.
11:16kchibisov: Like ideally you set `sync` on resizes, and then keep them desync.
11:17pq: yes, but even if a compositor implementation is fully correct protocol wise, the seams might show.
11:18pq: a compositor would need to do an intermediate composition of the window, and that would mostly void any benefits there were from sub-surfaces in the first place.
11:20kchibisov: That's true, but realistically you see csd decorations only on a few compositors, and even gtk does subsurfaces (just one though) iirc.
11:22kchibisov: Drawing decorations in your main surface could be better for perf in some clients, but it's way less convinient.
11:23pq: less convenient being better for perf seems like a universal truth :-)
11:24kchibisov: Also, decorations could be transparent, but main surface opaque, so main surface could be directly scanout.
11:24kchibisov: And decorations in real world are often has transparent hidden areas.
11:24pq: only as dmabuf
11:24kchibisov: That what I only do :p
11:25pq: btw. KMS does have some support for alpha-blending
11:25kchibisov: It does, but not all hardware can.
11:36pq: orowith2os, I still haven't read all gitlab backlog; both clients and compositors have the full right to have completely unusable GUI. It is not the protocol spec's purpose to demand that compositors and apps must "usable" - whatever that means. What do exist are app and compositor bugs and issues. All protocol violations are bugs, but not all bugs (or design choices) need to be protocol violations.
11:38pq: Wayland leaves much more things undefined than it defines, and that's fine. We still get usable apps and usable compositors, because they want to be usable, not because a spec says so.
11:40pq: I've had the same issue with some people about color management. It's hard to explain that things will be fine even if the protocol spec does not lock everyone into a single prescribed design.
11:40pq: or that one can still file bugs even if they are not protocol violations
11:46pq: what we do need to make clear is the language that a client and a compositor speak to each other, and what the words there mean, so anything that *is* communicated is understood the same way by everyone.
11:48pq: Before Wayland, the mantra was "mechanism, no policy". With Wayland, it's "descriptive, not prescriptive" which is almost the opposite.
12:15WhyNotHugo: cursor-shape doesn't allow hiding the cursor. Would be handy if wp_cursor_shape_device_v1::set_shape with shape==null hid the cursor.
12:17kchibisov: It was discussed, but it's expected that you use the `set_cursor` API.
12:53MrCooper: kchibisov: FWIW, AFAICT GTK4 no longer uses sub-surfaces itself
13:41swick[m]: if you're having meetings about wayland-protocols and we consider it a standards body you should probably also publish some minutes of the meeting
13:41swick[m]: seems a bit opaque what's going on right now
13:46MrCooper: I think the "meetings" are GitLab MRs/issues? :)
13:47wlb: weston Merge request !1298 opened by Marius Vlad (mvlad) clients/window: Allow smaller pending allocation in clients https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1298 [Desktop shell]
13:48pq: actually, I do know of one secret meeting about to happen
13:50emersion: sorry, we do have informal meetings sometimes
13:50emersion: has happened once for fractional-scale, and another time last week for… general stuff
13:51pq: I'm typing a request to be more open right now.
13:51emersion: i agree that discussing behind closed doors is not super great
13:52emersion: these meetings so far have been organized in an organic manner, soeone (generally from KDE ♥) says "we should talk" and then we do
13:54emersion: we do not have any person in charge of taking notes (i did try to take notes, but it's not exhaustive nor well-written)
13:56pq: are they audio calls or chat?
13:57emersion: audio calls
13:58wlb: weston Merge request !1299 opened by Marius Vlad (mvlad) desktop-shell: Handle all other shell surfaces in case of an output resize https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1299 [Desktop shell]
14:05wlb: weston Merge request !1300 opened by Marius Vlad (mvlad) backend-drm: Use resize_output to allow changing the fb https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1300 [DRM/KMS backend]
14:11psykose: emersion: spy!
14:12emersion: :D
14:43drakulix[m]: @pg agreed. I guess I should just sent out information on the next meeting on the mailing list then.
14:44drakulix[m]: Apologies, as emersion pointed out this developed quite organically, I'll certainly try to make the process more open next time.
15:09jadahl: being more public next time would be better indeed. the one that happened wal
15:09jadahl: last week was more grown out of "put wlroots and kde in a room" that leaked
15:09drakulix[m]: emersion: If you have notes from last time would you mind creating an issue for meeting notes and to summarize the last meeting? I'll try to do the same for the upcoming one.
15:09jadahl: leaked into others brain, I mean
15:22emersion: drakulix[m]: your email provider is generating DKIM signatures which are incompatible with mailing lists
15:23emersion: (ended up in my spam folder)
15:23emersion: (specifically, the ML adds a Sender header, and your DKIM signature forbits it)
15:24drakulix[m]: emersion: I used my company mail, so I am quite surprised by that.
15:32drakulix[m]: Thanks for the heads up though. I am trying to fix this. I guess this means I need to send out the mail again?
15:33emersion: i don't think it's necessayr
15:47swick[m]: drakulix: thanks!
16:41Company: swick[m], emersion: I think this "standards body" thing is not soemthing anyone can declare to be - it's earned when other assign that label to you
16:42emersion: nope
16:42Company: like, I don't think GTK devs consider any wayland entity to be in any way the arbiter for features GTK should implement
16:43emersion: that's not what a standards body is or does
16:43emersion: a standard body is a group of people who create standards
16:45emersion: Khronos publishes many extensions, and Khronos does not force vendors to implement the extensions
16:46emersion: the same goes for W3C, IRCv3, etc etc
16:46emersion: IETF
16:48Company: w3c works by Google submitting long drafts and Apple just implementing random things for iphones and then they argue in github issues why either approach is suboptimal
16:48psykose: sounds worse than w-p !
16:49Company: and it's still better than C++!
16:50Company: I think in general the wayland appraoch works quite well - like with the hdr / color amanagement stuff now
16:51Company: it just breaks down when multiple sides disagree on some fundamentals
16:51Company: but I don't think that's something you can change via the process
18:01dottedmag: Clarifying moments like "is w-p a standards body?" in documentation makes certain kinds of bad arguments to disappear, which raises the general level of discussion.
20:25orowith2os: what's the point of the single-pixel-buffer protocol? https://wayland.app/protocols/single-pixel-buffer-v1
20:25orowith2os: like, I get that it's for creating single-pixel buffers, but why would one want that?
20:28ifreund: to make surfaces with only a single color cheaper
20:28ifreund: (note that it can be used with viewporter as mentioned in the protocol)
20:29orowith2os: what would a real-world use case be?
20:29orowith2os: a GUI toolkit?
20:32kennylevinsen: orowith2os: solid background filling entire surface for example
20:32kennylevinsen: Using viewport
20:33rosefromthedead: i feel like we're going in circles here :P
20:33rosefromthedead: im writing a text editor and if kwin supported single-pixel-buffer then i'd be using them to draw the background, but really im not sure what that gets me other than changing the background colour being quick
20:33rosefromthedead: which is gonna happen maybe once a month for a weird user
20:34psykose: would it use less idle memory for just having the background painted or nah
20:34orowith2os: kennylevinsen oooh, I see it now. I'm going through some protocols I've never understood, reading them to see what I can make sense of
20:34kennylevinsen: Otherwise kind of expensive to fill a 4k monitor with black pixels - that's a 32MB buffer to fill. wldash2 (launcher) uses it for just that - then it only has to render the text bits here and there
20:34rosefromthedead: oh yeah that's why i did it LOL
20:35rosefromthedead: yeah my buffers that actually contain text can be smaller overall than the editor window, so the buffer is an easy way to fill in the whole background
20:35rosefromthedead: so it isn't transparent
20:36emersion: i use it for a client which gradually dims the screen
20:37emersion: also used by swaybg for solid color backgrounds
20:37emersion: some clients use it for window decorations
20:38orowith2os: huh, this is... interesting. I'd think KDE would have some of the best Wayland support out there based on their recent improvements, but even Mutter is ahead for what looks like generally useful protocols?
20:38orowith2os: depending on protocols, ofc
20:40orowith2os: okay, never mind, maybe?
20:40rosefromthedead: lol
20:40orowith2os: so far, it's presentation-time and single-pixel-buffer
20:41rosefromthedead: iirc the ones kwin has over mutter are generally the "insecure" ones like wlr-data-control
20:42rosefromthedead: ones which bring the missing features that plasma/xorg had
20:42orowith2os: seems more like "features" than features
20:43rosefromthedead: well, klipper is fluff right until you need it ;)
20:43orowith2os: I can see some more dedicated, secure APIs, like a portal, being more useful here?
20:44orowith2os: then you don't have random clients trying to be a clipboard manager :)
20:45emersion: wayland protocols can be secured
20:45orowith2os: (I still don't get the idea behind a "privileged" protocol)
20:46orowith2os: it sounds impossible without some form of sandboxing, so you don't have apps saying they're a shell when they're not
20:46emersion: yes, just like flatpak
20:46danieldg: orowith2os: basically yes, it requires either sandboxing or direct-launching of privileged helpers
20:47emersion: and then use security-context to figure out the sandbox for instance
20:47danieldg: the latter is mostly xwayland
20:47orowith2os: danieldg: oh, so Flatpak can enforce that apps don't try to use the wrong reverse-dns names?
20:48danieldg: yep
20:48danieldg: or to do thing that they aren't supposed to do (say, lock the screen)
20:48danieldg: *things
20:49orowith2os: can Flatpak also allow apps to take control of several names, or is it just the appid they're running inside of?
20:49orowith2os: I know they allow it for dbus, at least
20:50emersion: flatpak apps have a single appid
20:50emersion: afaik
20:50danieldg: libreoffice (which has a flatpak) does use multiple appids
20:50orowith2os: yeah, that's why you have permissions like --own-name
20:51rosefromthedead: if you want a client to be privileged, it has to open its wl connection in a special way right? or is there another way to identify trusted clients?
20:51orowith2os: danieldg: their appid on Flathub is org.libreoffice.LibreOffice, let me see what happens when it's installed
20:51orowith2os: rosefromthedead: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68
20:52danieldg: rosefromthedead: that's one way to do it; the other is to specifically de-privilege sockets that are used in sandboxes
20:52emersion: danieldg: only one flatpak app_id though, no?
20:52danieldg: emersion: correct
20:52danieldg: the reuse of appid for XDG is confusing
20:52emersion: yeah, i was talking about flatpak app_ids all along
20:52danieldg: yeah, I just realized that the names collided
20:54orowith2os: danieldg it looks like the LibreOffice flatpak only uses org.libreoffice.LibreOffice
20:54orowith2os: not even some extra --own-names, other than org.libreoffice.LibreOfficeIpc0
20:55orowith2os: there are several desktop files, but those aren't really relevant; you can have several desktop files within one appid
20:55danieldg: libreoffice has one flatpak appid, but multiple xdg/wayland app_id values (calc vs writer vs ...) - one per icon
20:55danieldg: I expect one desktop file per xdg appid
20:56orowith2os: is there a quick way I can check?
20:56orowith2os: the wayland app_id, that is
20:56danieldg: yes - /var/lib/flatpak/exports/share/applications has 8 .desktop files for it
20:57orowith2os: they're all within org.libreoffice.LibreOffice, at least
20:57danieldg: launch libreoffice and look at the window properties (with swaymsg -t get_tree for example)
20:57orowith2os: (on GNOME)
20:57danieldg: you can always launch with WAYLAND_DEBUG=1 and grep stderr for app_id
20:58danieldg: gnome might have a way to query appids but I don't know it
20:58orowith2os: ooooh this is cool
21:04orowith2os:sent a sh code block: https://matrix.org/_matrix/media/v3/download/matrix.org/DIiZpHDQqPtTcljnHxIezRcn
21:05orowith2os: not reverse-dns? huh
21:05danieldg: yeah, it's usually the icon name
21:06danieldg: I expect the actual .desktop field is StartupWMClass
21:10orowith2os: bingo
21:10orowith2os: StartupWMClass=libreoffice-startcenter
21:14orowith2os: if that's not set, it looks like the APPID is used, yeah
21:14orowith2os: GNOME Builder, both stable and devel, have their appids set according to their package
21:16orowith2os: this seems like it could cause issues, especially when it comes to bypassing the sandboxing, but w/e
21:19danieldg: one solution to this is to preface the application-provided app_id with the sandbox-provided ID (so org.libreoffice.LibreOffice.libreoffice-startcenter here), with similar changes to .desktop files so they are tied together
21:20danieldg: or, like dbus ownership, just have a list of "allowed" app_id values
21:32jadahl: orowith2os: iirc gnome-shell uses the flatpak app id for libreoffice as a "prefix" to allow associating e.g. writer vs calc with the right desktop file
21:45wlb: weston Merge request !1301 opened by Daniel Stone (daniels) tests: Initialise breakpoint list for all test types https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1301 [Testing]