08:37llyyr: what does xdg_toplevel activated state actually mean? Can I assume this to mean that the window is fully visible and not partially occluded by another window on top?
08:38llyyr: my use case is trying to detect when the user wants to drag the window or bring it to front by left clicking, instead of left clicking to trigger some keybind in the application
08:39llyyr: detecting keyboard/pointer focus works in some situations, but doesn't on focus-follows-cursor compositors where the window will get keyboard and pointer focus as soon as the cursor enters the window
08:39vyivel: "Can I assume this to mean that the window is fully visible and not partially occluded by another window on top?" no, a compositor may have multiple window layers (e.g. tiled/floating/always-on-top)
08:40llyyr: does any protocol provide any information to communicate user information in this case?
08:40llyyr: user intention*
08:40llyyr: whether they want to bring a window to the front or actually do whatever left click does in the application
08:40vyivel: the use case sounds strange to me, if i left click on a ui element in window i expect it to be triggered
08:41vyivel: "bringing a window to the front" is completely out of the application's scope, it's something only the compositor manages and should know about
08:41llyyr: the use case is mpv and seeing if it's possible to bind pause to left click, it'd be very annoying if mpv cycled pause everytime the user clicked on it to bring it to the front of the stack
08:42llyyr: I see that it's not possible then
08:42vyivel: i'd personally find it very annoying if i clicked on non-top-of-the-stack mpv and it didn't pause tbh
08:43llyyr: some users find it annoying the other way around, which is why it's bound to right click atm but we're trying to free up right click for a context menu :D
08:43vyivel: because that's not how every other program works
10:33emersion: I'd say this is better left as compositor policy
10:34emersion: compositor can intercept the left click event and not relay it if desirable
10:39llyyr: makes sense
10:55wlb: wayland/main: Demi Marie Obenour * connection: Fix wrong format string https://gitlab.freedesktop.org/wayland/wayland/commit/9cb3d7aa9dc9 src/connection.c
10:55wlb: wayland Merge request !443 merged \o/ (connection: Fix wrong format string https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/443)
11:46Company: zamundaaa[m]: ping?
12:44zamundaaa[m]: Company: pong?
12:46Company: zamundaaa[m]: I've been looking at the tag protocol and identifying toplevel in general
12:46Company: because it came up in a GTK MR
12:46Company: and that protocol is the only place that wants a translated string, not an untranslated one
12:46Company: so I was wondering why
12:47Company: I guess 2 subquestions:
12:47Company: 1. Why not also an untranslated string
12:47Company: 2. Why even a translated string at all
12:47emersion: my understanding is that the tag protocol wants an untranslated string
12:48emersion: IOW: the tag should not change based on user's language
12:49Company: It says "The tag may be shown to the user in UI" which to me always means translated
12:50Company: I was wondering if that's just because of Kwin rules using it so the string may end up in the config for that?
12:51Company: or if there was other places where you intended to use it
12:51emersion: maybe there's a misunderstanding about "human readable"
12:51emersion: as opposed to a random token or sth
12:52emersion: would be good to clarify
12:52Company: right
12:52Company: that may be
12:52Company: so the idea is that it says "main window" and does not use some GUID string
12:58Company: added https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/238#note_2681569 now
13:18zamundaaa[m]: Company: yeah it shouldn't be translated
15:52wlb: wayland Merge request !445 opened by () connection: properly use sendmsg(2) and recvmsg(2) https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/445
17:57wlb: wayland Merge request !412 closed (Fix various miscellaneous undefined behaviors)
18:01llyyr: wayland.app doesn't seem to have been updated in a long time now :(
18:02vyivel: idk seems more alive than dead https://github.com/vially/wayland-explorer/commits/main/
18:02llyyr: hmm, the core protocol xml isn't updated
18:02vyivel: would be nice to have a more official solution though
18:02llyyr: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/424 this for instance isn't in it
18:03vyivel: it's not released yet i think
18:03vyivel: ?
18:04llyyr: the commit messages suggests they update to latest git versions periodically
18:04llyyr: at least for wlr-protocols and wayland-protocols?
18:04vyivel: wlr- has no tags anyway, dunno about w-p
21:54wlb: weston Issue #978 opened by () Separate natural scrolling settings for different devices https://gitlab.freedesktop.org/wayland/weston/-/issues/978
22:02DemiMarie: Should there be a Wayland protocol for creating a popup at the current cursor position from an xdg-activation handle?