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