00:33 mclasen: any1: no such place around here, but I could be convinced to make the trek to weston
15:45 wlb: wayland Simon Ser pushed a new branch 1.23 https://gitlab.freedesktop.org/wayland/wayland/tree/1.23
15:45 wlb: wayland/1.23: Simon Ser * 7 commits https://gitlab.freedesktop.org/wayland/wayland/compare/0000000000000000000000000000000000000000...a9fec8dd65977c57f4039ced34327204d9b9d779
15:47 wlb: wayland New tag: 1.23.1 https://gitlab.freedesktop.org/wayland/wayland/tags/1.23.1
15:51 vyivel: nice hash heh
20:18 #dri-devel: DemiMarie: But that is a topic for #_oftc_#wayland:matrix.org
20:20 DemiMarie: Company: for GTK, adapting to server-side decorations might just mean not drawing close/minimize/maximize icons
20:20 #dri-devel: DemiMarie: #_oftc_#wayland:matrix.org
20:21 Company: there's also the problem that GTK treats the server side preference as a global thing and xdg-decoration doesn't have that concept
20:23 DemiMarie: what do you mean?
20:23 DemiMarie: as opposed to per-surface?
20:23 Company: yeah
20:24 Company: GTK does setup of the window before creating the Wayland resources
20:25 Company: so the assumption so far is that you can check the GdkDisplay to see if the server wants csd or ssd
20:25 Company: the org_kde_decoration protocol worked that way
20:26 emersion: i've suggested before to just make the GTK titlebar look like a toolbar
20:27 Company: yeah, just like i've suggested to just not draw decorations
20:27 Company: it's easy to point fingers at the other
20:28 emersion: some compositors _really_ can't
20:28 emersion: if GTK is in a tab in sway, there is _no way_ to not draw the titlebar for sway
20:28 emersion: GTK _can_ hide the buttons
20:28 Company: I'm aware
20:29 Company: yeah, just hiding the buttons is ertainly possible, but then you still have the titlebar
20:29 Company: well, potentially
20:30 Company: I would prefer the protocol to treat compositor and app as equals
20:31 emersion: i don't see what that would add
20:31 emersion: that wouldn't change anything for GTK
20:31 Company: it would change one important thing: people are not gonna blame GTK
20:31 Company: but instead blame both sides
20:32 emersion: good technical argument
20:33 Company: this has never been a technical argument but a game of 2 sides shouting at each other saying the other MUST act a certain way
20:33 emersion: there's no MUST - it's completely fine to not support the protocol if you really don't want to
20:33 emersion: it'
20:33 emersion: ll look bad, and that's it
20:34 Company: yeah, but if you support the protocol, you MUST do certain things
20:36 Company: I'd want a protocol that sees both sides as equals and says "both sides can do whatever they want but that may lead to a degraded user experience due to complete lack or duplication of decorations"
20:36 emersion: well of course, if you support the protocol, it means you support SSD to some extent
20:37 emersion: there is no upside to this apporach, only more complexity
20:38 Company: dunno
20:38 emersion: if both sides disagree, one _needs_ to have a final say
20:38 emersion: there's no way around it
20:38 Company: sure
20:38 Company: well
20:39 Company: currently both sides can do whatever they want
20:39 Company: but if both or neither draw decorations, it's suboptimal
20:39 mclasen: csd, on a weekend ?
20:39 mclasen:decides that it is too sunny outside for interminable discusions of unsolvable problems
20:40 emersion: that is very fair :D
20:40 llyyrr: is there a technical reason why gtk can't hide decorations or is it a philosophical one?
20:41 emersion: the headerbar has important things in it and is an integral part of the app
20:41 soreau: they put buttons critical to app operation in the titlebar for one
20:41 Company: llyyrr: the technical reason is that applications aren't tested to work without decorations
20:41 emersion: can't juts hide the thing
20:41 emersion: well
20:41 emersion: i have `gtk-decoration-layout=:`
20:41 emersion: good enough
20:41 Company: llyyrr: and just futzing with it can lead to degraded ui that's worse than just double drawing decorations
20:42 soreau: It should be just draw your square and let the compositor handle it
20:42 Company: soreau: people should have argued for that before Wayland's core protocol was settled
20:43 soreau: Company: there were many that yelled and whined but they were ignored
20:43 soreau: idk if you remember the topic here but it was banned from discussion at some point
20:43 soreau: like how are you supposed to shade a window? oh, now the client has to do it because, what?
20:44 emersion: … let's not rehash that one please
20:44 soreau: well shade is a new one
20:44 Company: hey, I wasn't a fan of csd but people pushed it into all the X WMs
20:44 Company: so GTK could do csd
20:44 soreau: if anyone is not familiar, you i.e. scroll on titlebar to have the window scroll up into the titlebar, so it becomes the size of the titlebar
20:45 soreau: shade
20:45 Company: and then people did Wayland and made it default
20:45 YaLTeR[m]: as far as im concerned if gtk responds to xdg-decoration SSD with the equivalent of the current xdg tiled state, that's already 90% of the way there
20:46 llyyrr: it might be hard to quantify how prevailing this opinion is, but gtk just supporting xdg-decoration and not drawing buttons when asked to not do csd would already be better than the status quo
20:46 soreau: yea, xdg-decoration support could help a lot
20:47 Company: one thing that would help would be a server preference, instead of just a per-surface one
20:48 soreau: there is in kde-decor protocol
20:48 Company: that's why gtk does kde-decor
20:48 soreau: well AFAIU, xdg-decoration does better negotiation
20:48 soreau: so upfront choice is not needed
20:48 Company: upfront choice is needed because that's how GTK works
20:49 soreau: now that's not a valid reason
20:49 Company: you look at the preference, then setup your window, then create the Wayland resources
20:49 Company: so the wl_surface is created after the GtkWindow exists
20:50 Company: but the wl_compositor exists before, as it's done in gtk_init()
20:50 soreau: If I had it my way, GTK would be able to use no, csd or ssd, selectable at runtime
20:50 soreau: from compositor options
20:50 Company: and we have gdk_display_prefers_ssd() or whatever that function is called
20:51 DemiMarie: Company: could GTK be changed to work the way xdg-decoration requires?
20:51 soreau: yes
20:51 soreau: any client can
20:51 Company: you can change everything
20:51 DemiMarie: Sway cannot not draw SSDs
20:51 Company: but I don't think it makes sense to just fudge with application UIs
20:52 Company: we had that issue 5-10 years ago with menus
20:52 DemiMarie: Does GTK draw the close button?
20:52 DemiMarie: Or does the app?
20:52 Company: when Unity wanted to show menus in the panel, like on mac OS
20:52 emersion: GTK does
20:52 Company: DemiMarie: usually the app instructs GTK to do it
20:52 Company: we have a GtkWindowControls widget
20:52 soreau: and gtk renders based on theme, basically
20:53 emersion: yeah, and can't that just be empty?
20:53 DemiMarie: so that widget could just be a no-op
20:53 Company: that can be empty, yeah
20:53 emersion: it already can be empty with a pref
20:53 Company: I think it's even fed via our platform settings
20:54 Company: you could probably override the platform setting for the buttons in the wayland setting code based on decoration
20:55 immibis: why would the protocol treat compositor and app as equals? they are not equals
20:55 Company: immibis: depends on your pov
20:56 immibis: yes a whole lot of people thought mandatory CSD was bass-ackwards and they were completely ignored, shouted over, and banned.
20:56 Company: both the app and the compositor can draw whatever they want and the other side can't do anything about it
20:56 immibis: well yes but the point of a protocol is to agree on a set of rules so things work together properly
20:56 immibis: otherwise may as well just take the raw protocol byte stream, shove it into the framebuffer and claim support
20:57 Company: yeah, but that kinda implies that they should be treated equally
20:57 Company: the protocol shouldn't feel like one side gets to make the rules
20:57 immibis: many protocols involve clearly separated roles, for example HTTP has a client and a server
20:57 emersion: compositor having the final say is a core principle of wayland, fwiw
20:57 immibis: the client doesn't have to send response codes and the server doesn't have to choose the method, because that wouldn't make sense
20:58 immibis: SSD is a reasonable default because that's the way literally everyone (except gnome developers) expects windowing systems to work; CSD can then be negotiated easily enough. Going the other way is more painful.
20:58 soreau: emersion: that should be documented :P
20:59 Company: immibis: that's the compositor pov - for an app csd is much easier, because it can allow the app dev to do whatever they want
20:59 immibis: my current window manager in X doesn't have decorations, but it's still in charge of providing ways to close/move/open windows which is the same thing
20:59 YaLTeR[m]: windows and macos are both CSD as far as I understand
20:59 immibis: Company: CSD is not easier for apps. YaLTeR[m]: only from a system internals perspective. The API boundary is different from the IPC boundary, and puts decoration responsibility in the windowing system, not the app.
20:59 Company: YaLTeR[m]: it's tricky, because you can't do whatever if you want aerosnap etc to work
21:00 immibis: notice that on windows, the client library and the server are tightly coupled
21:00 Company: immibis: the app can be csd or ssd, and the toolkit/compositor just draws controls if the app is ssd
21:00 immibis: I think the same is also true on mac.
21:00 karolherbst: before this discussion gets out of control and heats up on both sides, I'd advise everybody to stay constructive, and not point fingers or make judgement of whatever option/default/something is the better solution, because everybody is allowed to have different opinions here
21:00 soreau: karolherbst: thanks
21:01 Company: to me the solution is to say "both sides are equal, and both sides are allowed to say I WILL DO NOTHING BUT X" and then the protocol defines what happens if they do insist - ie double decorations or no decorations and that's fine if they insist
21:02 soreau: The protocol shouldn't allow for broken-looking-to-users rendering
21:03 immibis: if both sides insist on server-side decorations there will be double decorations and if both sides insist on client side decorations there will be none. And if my compositor insists on piping the protocol stream to the framebuffer while my app insists on sending commands instead of raw pixel data, the screen will show snow.
21:03 soreau: remember, it was supposed to be every frame is perfect
21:03 Company: soreau: frames are only perfect if both sides make it so
21:04 immibis: the point of a protocol is that you follow it and get the benefits. if the protocol makes every frame perfect but every frame is not perfcet then someone is lying.
21:04 soreau: Company: well the protocol should make it clear what should or shouldn't happen
21:04 Company: yeah
21:04 Company: that's why I'm saying that it's fine to have no or double decorations if both sides insist
21:05 soreau: not if the protocol says otherwise
21:05 soreau: why would it permit that
21:05 Company: because it wants both sides to be able to insist
21:05 immibis: then the protocol is broken
21:06 immibis: broken, worth only the paper it's printed on, not fit for purpose,
21:06 Company: dunno
21:06 soreau: It would make it easiest to do things the X way and would solve the theming issue, then there wouldn't be an issue to argue
21:06 soreau: then you could talk about protocols to put buttons or whatever might be supported by your decorator
21:06 immibis: the X way as in SSD?
21:07 soreau: I think the reason why CSD in the first place is because it was easiest from POC POV
21:07 soreau: immibis: yes
21:07 Company: no, the reason why csd is why gnome did a huge push for csd 10-15 years ago
21:08 soreau: I don't think krh made the CSD option because gnome said so
21:08 Company: and it was as insanely complicted to get that working on all the X WMs and people didn't want to do that again
21:08 karolherbst: I don't think this discussion makes sense to continue if nobody wants to move from their position
21:08 immibis: well the easiest POC is one with no decorations at all, and you sort them out later. AFAIK that's the reason X11 displaced X10.
21:08 immibis: X11 figured out a way for window managers to draw decorations
21:09 soreau: Company: so do you think gtk will support xdg-decoration or patches would be accepted to support it?
21:09 immibis: i also read somewhere wayland was originally designed for small systems, like in-car entertainment, where there just aren't decorations.
21:09 Company: soreau: I looked at it and the main problem is gdk_display_prefers_ssd()
21:09 soreau: Company: you mean the upfront option?
21:10 Company: soreau: yeah
21:10 soreau: I don't really see why you can't just do what other xdg-decoration clients do
21:10 Company: soreau: other than that, GTK could jsut behave as with kde_decor and send what it does
21:11 mclasen:opens a beer
21:11 soreau: mclasen: what, didn't bring enough for everyone?
21:11 Company: and then once the protocol exists - without any changes to GTK's API - people can propose patches
21:12 Company: all the MRs that exist in GTK so far were redesigning half of the API while trying to add the protocol
21:14 emersion: the problem to "specific client internals don't support it atm" isn't "let's create a new protocol for it and make everyone else implement it", in general
21:14 soreau: Company: so there's a chance for xdg-decoration but not high on priority for gtk since it doesn't really matter much one way or the other to gtk?
21:15 Company: soreau: I would say there's a lot of resistance inside GTK, so wanting toadd it should be a careful process and not come with tons of demands or the pushback will kill any attempts
21:15 Company: soreau: like the 3-5 previous attempts
21:15 soreau: I see
21:16 Company: I personally only have 1 requirement: GTK apps only need to support 1 method, and for GTK 4, that one method is CSD
21:17 Company: gtk apps can also select SSD (then GTK draws decorations I think, not sure if it lets the compositor do it on Wayland, it does in X11 I think)
21:18 Company: for further work, the goal from my pov would be to make it possible for apps to opt-in to SSD somehow
21:18 kchibisov: Can't gtk always draw CSD when user adds something into decorations and otherwise follow system?
21:18 Company: and to do things like figuring out if the decoration preferences of the compositor can be used to do things like hide buttons
21:19 soreau: at least on gtk3, we can choose whether gtk3 apps start with ssd or csd
21:19 Company: kchibisov: that's kinda how it works on X11 I think
21:19 soreau: in wayfire
21:19 Company: kchibisov: but I have no idea if that's implemented on Wayland or if it always uses GTK-provided decorations
21:20 immibis: I read somewhere GTK only wants to work on GNOME's compositor anyway
21:20 immibis: they're trying to create a fully integrated ecosystem, no?
21:21 psykose: this discussion has it all
21:21 kchibisov: The point is with GTK's decorations is that they carry a lot of buttons.
21:22 Company: GTK apps usually have system decorations next to application buttons
21:22 kchibisov: so it doesn't make any sense to push for obey ssd because it won't really work. The only place where it _should_ work is when using default gtk titlebar, because it has the same functionality as default server side.
21:22 Company: I think the only system button Gnome has by default is close?
21:22 kchibisov: I think you can adjust it via ipc.
21:23 kchibisov: but if application designed to rely on decorations, I don't see anything bad in it.
21:23 kchibisov: e.g. rnote.
21:23 Company: yeah, https://release.gnome.org/46/file-ops-screenshot.png ony has the close button
21:24 psykose: hm why is that downward arrow next to the close blurry
21:24 kchibisov: I think other proposal was to also hide those wm buttons when xdg-decor is used.
21:25 Company: because arrows are drawn using a different codepaths than icons
21:42 DemiMarie: To me, the compositor choosing server-side decorations does not compel the client to stop drawing decorations.
21:43 DemiMarie: My interpretation is that the compositor will be drawing server-side decorations, and the client is being informed of this fact.
21:43 DemiMarie: The client is expected to adapt, but how it adapts is entirely client-specific.
21:44 soreau: well of course the client can draw whatever it wants in its bag of pixels
21:45 DemiMarie: exactly
21:45 DemiMarie: I’m not expecting GTK apps to stop having a titlebar.
21:46 soreau: but if the protocol says SSD can't have CSD decorations.. you can bend that rule all kinds of ways, that's the problem
21:46 DemiMarie: yup, that’s too strong
21:47 DemiMarie: I would say that the client is expected to stop drawing outside of its toplevel geometry and to otherwise adapt in an unspecified way.
21:47 DemiMarie: Possibly give some non-normative examples.
21:47 soreau: alternatively, the compositor can make a mess of things and just decorate all toplevels - but it wouldn't be if the client was just expected to always be SSD'd
21:47 DemiMarie: There are compositors that must decorate all toplevels.
21:47 soreau: and that would be easiest for clients to imeplement
21:48 immibis: apps are allowed to put anything they want on the screen, whether that's extra close buttons or pornography, but that doesn't mean that's good app design and the protocol should let the app know whether there's already a close button on the screen.
21:48 immibis: there are windows apps with extra close buttons even though windows always adds a close button (in most cases)
21:49 DemiMarie: I think that it is assumed that a compositor that provides SSDs will provide a close feature, though it might not be a button.
21:49 Company: (in Windows the app can do whatever)
21:50 Company: (that's how Winamp has always worked)
22:01 soreau: there are apps where csd makes sense (like winamp since it's fully self-themed) but toolkits should just not render decorations because ssd solves the inconsistent theming problem
22:03 soreau: csd just doesn't seem to be a great fit for different toolkits collectively
22:03 soreau: so it would be nice if toolkits would at least consistently provide the option of ssd
22:04 soreau: apps shouldn't rely on buttons in the titlebar IMHO
22:04 Company: from a toolkit pov the best thing is to let the app decide
22:04 Company: and having a compositor that does whatever the app chooses
22:05 soreau: well in many ways, this is how it is already
22:05 mclasen:will not listen to 'inconsistent theming' arguments
22:06 soreau: the compositor is forced to bend to the client because double decorations or no decorations are probably considered compositor bugs regardless what the client is doing
22:06 soreau: (following protocol or not)
22:06 Company: depends
22:06 DemiMarie: soreau: my compositor won’t bend to the client
22:06 soreau: DemiMarie: then your compositor seems buggy to your users
22:06 Company: no decorations are considered application bugs
22:07 Company: there was a whole Factorio blog post about having to draw decorations because Mutter wouldn't
22:07 DemiMarie: soreau: no, my compositor will be doing exactly what Qubes OS users not only expect but rely on for security
22:07 mclasen: then there's no need to argue
22:08 mclasen: do what you think you gotta do
22:18 DemiMarie: that said, what I would prefer is a Wayland protocol that everyone can agree on
22:26 zamundaaa[m]: Company: if the app requests SSD, and the compositor doesn't draw it, that's a compositor bug. Or the intended experience, depends on the use case (mobile doesn't want decorations in the normal sense)
22:26 zamundaaa[m]: But let's not mix the compositor side support discussion with the GTK one, they are pretty separate issues
22:28 zamundaaa[m]: From a GTK POV, what you mostly seem to need is a way to tell the compositor that a specific window won't work too well with SSD
22:28 Company: DemiMarie: it's easy, you just need to find a solution that sway, mutter and gtk agree on: The compositor will draw decorations, the compositor will not draw decorations and the app chooses if it draws decorations or not
22:29 DemiMarie: Company: and the app knows if the compositor draws decorations and can adjust accordingly
22:29 zamundaaa[m]: Right? So when the compositor chooses SSD anyways, that's either an explicit user choice, is required for the specific use case, or a compositor bug, and not something you have to deal with too much
22:30 DemiMarie: Company: is it reasonable to expect the client to stop drawing shadows when SSDs are in use?
22:30 DemiMarie: Drawing shadows that will just be clipped is a waste of resources and best avoided.
22:30 Company: DemiMarie: I think that's doable - I can think of one special usecase where that doesn't work, but in general that should work
22:31 Company: for shadows/rounded corners, GTK has different style classes on the window, they just need to be set properly
22:31 Company: of course, people can write custom themes that do whatever, but GTK proper and Adwaita do what you expect
22:32 DemiMarie: Company: glad to hear that!
22:32 Company: but I have no idea if/how that's implemented for Wayland
22:32 Company: it is implemented for mac OS though
22:32 DemiMarie: That’s fine.
22:33 Company: gtk has a mode for tiling/maximized where it doesn't draw shadows (or corners)
22:33 DemiMarie: Having SSDs enable that should work.
22:34 Company: there is a bunch of progress possible, but so far nobody was willing to be reasonable, so nothing happened
22:34 DemiMarie: I hope I am being reasonable here
22:34 Company: turning that into merge requests that won't be shut down is the hard part
22:35 DemiMarie: what caused the previous MRs to be closed?
22:35 soreau: it's easier to just pop a fork and do the expected thing
22:35 karolherbst: what are the kind of changes people proposed here on the gtk side anyway?
22:36 soreau: karolherbst: I think Company is saying that only clients should be in control and compositor should obey
22:36 soreau: but emersion indicated otherwise
22:36 karolherbst: that's not an answer to my question
22:37 Company: karolherbst: changes to xdg_decoration or changes to GTK?
22:37 zamundaaa[m]: karolherbst: support xdg decoration, and when the compositor forces SSD, just hide shadows, rounded corners and ideally the minimize/maximize/close buttons
22:37 soreau: karolherbst: oh, I must have misunderstood your question
22:37 karolherbst: the MR proposed to gtk to implement the extension, and what kind of changes they wanted to do
22:37 soreau: oh
22:38 karolherbst: so far I got that they tried to change the gtk API, I'm mostly curious to what degree they tried that
22:39 Company: karolherbst: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6398
22:39 karolherbst: I see
22:40 Company: that's the GTK4 one, there's 2 others for GTK3
22:43 Company: it's also a bit of a psychological thing - there's 2 sides with pitchforks and nobody wants to move, so if you do too many changes at once, the shouting matches start again
22:43 karolherbst: zamundaaa[m]: yeah... sounds reasonable, I can totally understand that heavily CSD focused apps just won't look great with SSD enforced, but getting rid of those "default buttons" at least will prevent it to be too terrible
22:44 karolherbst: yeah... CSD vs SSD discussions are rarely the type of discussions to go smoothly in my experience
22:44 mclasen: there's no pitchforks on my side
22:45 mclasen: I'm simply not going to accept a protocol implementation that forces ssd on unsuspecting apps
22:46 soreau: but maybe they should be expecting it
22:46 Company: yeah
22:46 zamundaaa[m]: mclasen: SSD is already being forced on these apps
22:46 Company: but that's the psychological part
22:47 zamundaaa[m]: Not supporting the protocol doesn't really change what compositors with specific requirements do
22:47 Company: if people go with pitchforks into the app's issue tracker and say "GTK supports that protocol, you must work with SSD now" then I've failed
22:47 karolherbst: yeah... you can just be a little nicer than doing thing
22:47 karolherbst: s/thing/nothing/
22:47 mclasen: zamundaaa: thats between your compositor and you
22:48 zamundaaa[m]: mclasen: GTK not supporting the protocol doesn't change that a lot
22:48 Company: people are less likely to do that if the spec says "apps and compositors are expected to come to an agreement and if they don't you get double decorations."
22:48 mclasen: then whats the fuss about ?
22:48 zamundaaa[m]: But I understand that the situation isn't ideal
22:48 karolherbst: it's not like any protocol can make CSD apps to be SSD "native" ones, so all it could ask for is to e.g. stop drawing shadows and other things which really make no sense
22:48 karolherbst: but anyway...
22:49 karolherbst: something for you all to figure out
22:49 soreau: I think what might make this more palatable, is if the client were in control but the options of csd/ssd worked during runtime with whatever config setting tickles it, regardless if the client mistakenly put mission critical buttons in its csd
22:50 zamundaaa[m]: mclasen: would you be okay with the protocol if GTK could tell the compositor that you don't get a good result if the compositor forces SSD?
22:52 soreau: It seems like the idea of 'I am a client with buttons in csd so you cant ssd me without doubling up' has to go away, to make any progress
22:52 Company: zamundaaa[m]: I would do an enum { WILL_DO_CSD, PREFERS_CSD, DONT_CARE, PREFERS_SSD, WILL_DO_SSD } in the protocol (no idea if DONT_CARE is necessary)
22:53 Company: zamundaaa[m]: and then both client and server announce their side, and then you define who in those 5x5 combinations does what
22:53 zamundaaa[m]: I don't think we need to make it that complicated. Just have the client send the modes it can currently reasonably support, in addition to the existing preference
22:54 zamundaaa[m]: Or do https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/176
22:54 mclasen: all this seems like an extreme complication of the simple idea that when the client tells you to leave it alone, just leave it alone
22:54 zamundaaa[m]: Bah, Firefox did a stupid
22:54 Company: zamundaaa[m]: wrong link?
22:54 zamundaaa[m]: I meant https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/17
22:55 zamundaaa[m]: mclasen: that's not how it works
22:55 DemiMarie: mclasen: not every compositor is capable of that
22:55 zamundaaa[m]: If the user tells KWin to force SSD, then it'll force SSD
22:55 mclasen: DemiMarie: I consider your use case to be entirely separate and not really relevant for this dicussion
22:56 DemiMarie: mclasen: fair
22:56 mclasen: if your customers require security levels color-coded in window decorations, you gotta do what you gotta do
22:56 soreau: it's not about whether the compositor is capable, it's about choice, in the end
22:56 karolherbst: though there are other compositors which also force SSD, e.g. VR ones, no?
22:56 mclasen: double decorations will be a minor nuisance in that situation
22:56 DemiMarie: mclasen: would it help to guarantee that `zxdg_decoration_manager_v1.get_toplevel_decoration` has no side effects?
22:57 zamundaaa[m]: mclasen: the protocol has to cover all reasonable use cases
22:57 Company: zamundaaa[m]: I think what happens in GTK is that users set a custom "title" widget
22:57 zamundaaa[m]: Demi's might be a bit out there, but tiling compositord aren't
22:58 Company: zamundaaa[m]: if they didn't set one, GTK adds its own title on Wayland or switches to SSD on X11
22:58 Company: zamundaaa[m]: changing that to switch to SSD on Wayland would be one thing you could do
22:58 Company: zamundaaa[m]: problem: Almost all Adwaita apps set a title widget
22:59 Company: even gtk-demo does these days
22:59 mclasen: we do that already
22:59 Company: do we?
23:00 zamundaaa[m]: Company: these apps are meant for CSD, right? So that would be fine
23:00 mclasen: if you you don't set a custom titlebar, ssd works
23:00 mclasen: at least, it is meant to work
23:00 soreau: yes it does
23:00 DemiMarie: Nit: Qubes OS isn’t my project. I’m just the one currently responsible for Wayland and GPU work.
23:00 soreau: at least at startup
23:00 Company: I thought it only works on X11, that's neat then
23:01 soreau: if you try to change it at runtime it just spits back at you what the initial server choice was.. unless it has titlebar widget, then it's all csd all the time
23:01 Company: the other thing is hiding window buttons - that should be reasonably easy - even in csd apps
23:01 Company: the question is how you determine that they should be hidden
23:01 zamundaaa[m]: You hide them when the compositor tells you it's doing SSD
23:02 Company: yeah, that just requires doing the plumbing
23:02 Company: currently we don't even track what the compositor does I think - apart from the global preference sent via kde_decor
23:02 Company: but that setting is global anyway
23:03 zamundaaa[m]: In kde decoration you don't need to track it, yeah
23:03 Company: which is the other thing - compositor ssd preference is a global thing in gtk
23:03 Company: because we read that setting from XSettings or dconf in Wayland
23:04 soreau: well it's also 'read' from the kde protocol from the server on app start
23:05 soreau: Company: because even if you set the 'global' preference to ssd, titlebar widget apps will still have csd, right?
23:05 Company: yes
23:06 soreau: hm, don't even honor your own settings :P
23:06 Company: I don't know what the preference does in detail
23:07 soreau: smh
23:16 Company: zamundaaa[m]: one fun example app I have is my playback tool that takes a frame from an app and plays it back as-is
23:17 Company: which I use for debugging, ie when there's a rendering error caused by some weird interaction (ie we pick the wrong colorstate in the HDR stuff)
23:18 Company: that app can't and doesn't want to do anything different than when it was recorded, because it's literally just replaying instructions
23:19 Company: it's essentially like a splash screen
23:19 zamundaaa[m]: That would definitely be a good case for giving the client a way to set what it can handle well, both in CSD and SSD direction
23:20 zamundaaa[m]: Just set whatever state the window had when it was recorded
23:33 Company: zamundaaa[m]: btw, it's pretty much where all the screenshots you've seen about HDR come from - and why when I post 2 screenshots for comparison the contents in the GTK app look identical - there'd be no way to do that without that tool