01:02 Dami_Lu: davidre：After the focus is switched to the parent window, will the child window still be on top of the parent window?
01:03 Dami_Lu: I can provide a complete example if needed
01:09 ManMower: Dami_Lu: please see https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml?ref_type=heads#L657
01:09 ManMower: the xdg shell parent/child relationship is defined to provide the behaviour you're seeing. if you want different behaviour, do not use it.
01:11 Dami_Lu: thanks, Then I can understand that this is a problem under X, or I can understand that it is designed like this under wayland.
01:13 ManMower: it may be a problem with a toolkit you're using, if it's using set_parent in a situation where the windows should not be stacked like this. but wayland and X are not the same - xdg_toplevel.set_parent wasn't designed to exactly mimic a specific X function call
01:21 Dami_Lu: It is not necessarily stacking. The parent-child relationship of the setting window is the same, but under wayland, the parent-child relationship binding is implemented using xdg_toplevel.set_parent. Is it possible to consider adding a request to handle such demand scenarios?
16:16 |: https://www.phoronix.com/news/Wayland-Proxy-Firefox I'm looking at this and suddenly curious about putting apache kafka between apps and a wayland compositor
16:17 |: Like subscribing to different events - idle inhibitors, lock screen, geometry changes, focus grabs, as kafka topics
16:17 |: but not sure how practical that actuall is, it just seems like a win to have isolated control of those message queues and subscriptions
16:18 |: with the added benefit of them being reachable over a network?
16:43 kennylevinsen: |: not possible - Wayland protocols often send file descriptors instead of encoding the data itself
16:45 kennylevinsen: Plus, it doesn't really make sense. Wayland is already an asynchronous message system, why put it through another asynchronous message system with more moving parts to break and specifications to deal with?
16:47 kennylevinsen: (The Firefox usecase is special because of some very Firefox-specific design problems)
17:56 |: I was thinking if you could isolate messages from clients into topics in kafka, you could prioritize handling their changes in the compositor too. like nice'ing a non-gui app. I dunno, I just saw some of the message-queuing, subscribing, partitioning, features as attractive and something I wouldn't want to implement again in the compositor. but I do admit I'm no expert here
17:58 |: and being able to dynamically move a client from this compositor to another, over the network, or replay events like a backtrace from the messaging queue - there's probably much better ways to do this than shoehorn in kafka.
17:58 |: I have kafka fever.
18:27 kennylevinsen: |: if a compositor wanted to handle things with different priority it could do so already. Kafka would not enable any of those use-cases - e.g., logging all events is a built-in debug feature in libwayland and therefore more or less all Wayland clients and servers
18:36 kchibisov: kennylevinsen: firefox is solving not special to firefox problem though.
18:37 kchibisov: Like the issue is a real problem, there's even a patch on wayland/wayland to address it.
18:43 kchibisov: it's just sad that the work stalled and we have workarounds like that.
19:07 kennylevinsen: kchibisov: their fix and severity is specific to them
19:07 kchibisov: idk, I have people from time to time complaining that their high res mouse crashes window.
19:08 kchibisov: outside of e.g. alacritty, but in general, it's not uncommon.
19:09 kennylevinsen: Yeah but Firefox is weird because they are trying to be a direct Wayland client while also using Gtk, so they don't have the control of things they want/need
19:10 kchibisov: yeah, but expecting that 4KiB is enough for everyone is not gret.
19:10 kennylevinsen: And the problem is much worse for them because they dispatch a ton of things to their main thread - iirc, this includes JavaScript
19:11 kennylevinsen: The problem with the Wayland connection buffers definitely is real, but Firefox is also definitely weird
19:13 kchibisov: yeah, but it doesn't justify that firefox issue can't be solved with unbounded buffer.
19:14 kchibisov: especially when we have patch around for year.
19:16 Arnavion: Why wasn't this a problem with X's socket?
19:17 kchibisov: it's an implementation detail of libwayland , Arnavion
19:18 kennylevinsen: I'm not a fan of that solution. I feel that either some fixed size is sufficient, or a mechanism is needed to halt events until responsive
19:18 kchibisov: kennylevinsen: you've seen that it could be controlled?
19:18 Arnavion: What's an implementation detail? That the server closes the socket when it can't write?
19:19 kchibisov: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188
19:19 Arnavion: Yes, so again, why wasn't this a problem with X? What does Xorg do when it can't write to the socket?
19:20 Arnavion: (I assume it doesn't just block)
19:21 kchibisov: I'm not familiar what xorg is doing, but the communication is via the same mechanism so it's not like you have that many options.
19:22 Arnavion: Yes, that's why I'm curious why firefox etc only see this problem with wayland and not before
19:23 kchibisov: I think one part of it is how communication is built, given that X in general gives more freedom on how you can do things.
19:24 kchibisov: And with wayland the state is you libwayland or die.
19:26 kchibisov: But I'm not familiar with firefox architecture to argue about that.
21:37 wlb: wayland Issue #430 opened by Marcos Dione (mdione) Wishlist: user actvity API https://gitlab.freedesktop.org/wayland/wayland/-/issues/430