ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
iconoclasthero has quit []
RAOF has quit [Remote host closed the connection]
RAOF has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
Brainium has quit []
<mclasen>
any1: no such place around here, but I could be convinced to make the trek to weston
CodeSpelunker has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
fmuellner has joined #wayland
sima has quit [Ping timeout: 480 seconds]
narodnik has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
rasterman has quit [Remote host closed the connection]
mclasen has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
mclasen has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
ity has quit [Quit: WeeChat 4.3.5]
iconoclasthero has quit [Ping timeout: 480 seconds]
sima has joined #wayland
coldfeet has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
rasterman has joined #wayland
qyliss has quit [Quit: bye]
qyliss has joined #wayland
Narrat has joined #wayland
thevar1able_ has quit [Remote host closed the connection]
thevar1able_ has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
rv1sr has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
iconoclasthero has joined #wayland
Brainium has joined #wayland
Brainium has quit []
Brainium has joined #wayland
flom84 has joined #wayland
___nick___ has quit [Remote host closed the connection]
rgallaispou has quit [Read error: Connection reset by peer]
sima has joined #wayland
flom84 has quit [Quit: Leaving]
<DemiMarie>
Company: for GTK, adapting to server-side decorations might just mean not drawing close/minimize/maximize icons
<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
<DemiMarie>
what do you mean?
<DemiMarie>
as opposed to per-surface?
<Company>
yeah
<Company>
GTK does setup of the window before creating the Wayland resources
<Company>
so the assumption so far is that you can check the GdkDisplay to see if the server wants csd or ssd
<Company>
the org_kde_decoration protocol worked that way
<emersion>
i've suggested before to just make the GTK titlebar look like a toolbar
<Company>
yeah, just like i've suggested to just not draw decorations
<Company>
it's easy to point fingers at the other
iconoclasthero has quit [Ping timeout: 480 seconds]
<emersion>
some compositors _really_ can't
<emersion>
if GTK is in a tab in sway, there is _no way_ to not draw the titlebar for sway
<emersion>
GTK _can_ hide the buttons
<Company>
I'm aware
<Company>
yeah, just hiding the buttons is ertainly possible, but then you still have the titlebar
<Company>
well, potentially
<Company>
I would prefer the protocol to treat compositor and app as equals
<emersion>
i don't see what that would add
<emersion>
that wouldn't change anything for GTK
<Company>
it would change one important thing: people are not gonna blame GTK
<Company>
but instead blame both sides
<emersion>
good technical argument
<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
<emersion>
there's no MUST - it's completely fine to not support the protocol if you really don't want to
<emersion>
it'
<emersion>
ll look bad, and that's it
<Company>
yeah, but if you support the protocol, you MUST do certain things
iconoclasthero has joined #wayland
<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"
<emersion>
well of course, if you support the protocol, it means you support SSD to some extent
<emersion>
there is no upside to this apporach, only more complexity
<Company>
dunno
<emersion>
if both sides disagree, one _needs_ to have a final say
<emersion>
there's no way around it
<Company>
sure
<Company>
well
<Company>
currently both sides can do whatever they want
<Company>
but if both or neither draw decorations, it's suboptimal
<mclasen>
csd, on a weekend ?
* mclasen
decides that it is too sunny outside for interminable discusions of unsolvable problems
<emersion>
that is very fair :D
<llyyrr>
is there a technical reason why gtk can't hide decorations or is it a philosophical one?
<emersion>
the headerbar has important things in it and is an integral part of the app
<soreau>
they put buttons critical to app operation in the titlebar for one
<Company>
llyyrr: the technical reason is that applications aren't tested to work without decorations
<emersion>
can't juts hide the thing
<emersion>
well
<emersion>
i have `gtk-decoration-layout=:`
<emersion>
good enough
<Company>
llyyrr: and just futzing with it can lead to degraded ui that's worse than just double drawing decorations
<soreau>
It should be just draw your square and let the compositor handle it
<Company>
soreau: people should have argued for that before Wayland's core protocol was settled
<soreau>
Company: there were many that yelled and whined but they were ignored
<soreau>
idk if you remember the topic here but it was banned from discussion at some point
<soreau>
like how are you supposed to shade a window? oh, now the client has to do it because, what?
<emersion>
… let's not rehash that one please
<soreau>
well shade is a new one
<Company>
hey, I wasn't a fan of csd but people pushed it into all the X WMs
<Company>
so GTK could do csd
<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
<soreau>
shade
<Company>
and then people did Wayland and made it default
vyivel has left #wayland [#wayland]
<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
<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
<soreau>
yea, xdg-decoration support could help a lot
<Company>
one thing that would help would be a server preference, instead of just a per-surface one
<soreau>
there is in kde-decor protocol
<Company>
that's why gtk does kde-decor
<soreau>
well AFAIU, xdg-decoration does better negotiation
<soreau>
so upfront choice is not needed
<Company>
upfront choice is needed because that's how GTK works
<soreau>
now that's not a valid reason
<Company>
you look at the preference, then setup your window, then create the Wayland resources
<Company>
so the wl_surface is created after the GtkWindow exists
<Company>
but the wl_compositor exists before, as it's done in gtk_init()
<soreau>
If I had it my way, GTK would be able to use no, csd or ssd, selectable at runtime
<soreau>
from compositor options
<Company>
and we have gdk_display_prefers_ssd() or whatever that function is called
rasterman has quit [Quit: Gettin' stinky!]
<DemiMarie>
Company: could GTK be changed to work the way xdg-decoration requires?
<soreau>
yes
<soreau>
any client can
<Company>
you can change everything
<DemiMarie>
Sway cannot not draw SSDs
<Company>
but I don't think it makes sense to just fudge with application UIs
<Company>
we had that issue 5-10 years ago with menus
<DemiMarie>
Does GTK draw the close button?
<DemiMarie>
Or does the app?
<Company>
when Unity wanted to show menus in the panel, like on mac OS
<emersion>
GTK does
<Company>
DemiMarie: usually the app instructs GTK to do it
<Company>
we have a GtkWindowControls widget
<soreau>
and gtk renders based on theme, basically
<emersion>
yeah, and can't that just be empty?
<DemiMarie>
so that widget could just be a no-op
<Company>
that can be empty, yeah
<emersion>
it already can be empty with a pref
<Company>
I think it's even fed via our platform settings
<Company>
you could probably override the platform setting for the buttons in the wayland setting code based on decoration
<immibis>
why would the protocol treat compositor and app as equals? they are not equals
<Company>
immibis: depends on your pov
<immibis>
yes a whole lot of people thought mandatory CSD was bass-ackwards and they were completely ignored, shouted over, and banned.
<Company>
both the app and the compositor can draw whatever they want and the other side can't do anything about it
<immibis>
well yes but the point of a protocol is to agree on a set of rules so things work together properly
<immibis>
otherwise may as well just take the raw protocol byte stream, shove it into the framebuffer and claim support
<Company>
yeah, but that kinda implies that they should be treated equally
<Company>
the protocol shouldn't feel like one side gets to make the rules
<immibis>
many protocols involve clearly separated roles, for example HTTP has a client and a server
<emersion>
compositor having the final say is a core principle of wayland, fwiw
<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
<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.
<soreau>
emersion: that should be documented :P
<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
<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
<YaLTeR[m]>
windows and macos are both CSD as far as I understand
<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.
<Company>
YaLTeR[m]: it's tricky, because you can't do whatever if you want aerosnap etc to work
<immibis>
notice that on windows, the client library and the server are tightly coupled
<Company>
immibis: the app can be csd or ssd, and the toolkit/compositor just draws controls if the app is ssd
<immibis>
I think the same is also true on mac.
<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
<soreau>
karolherbst: thanks
<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
mclasen has quit [Ping timeout: 480 seconds]
<soreau>
The protocol shouldn't allow for broken-looking-to-users rendering
<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.
<soreau>
remember, it was supposed to be every frame is perfect
<Company>
soreau: frames are only perfect if both sides make it so
<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.
<soreau>
Company: well the protocol should make it clear what should or shouldn't happen
<Company>
yeah
<Company>
that's why I'm saying that it's fine to have no or double decorations if both sides insist
<soreau>
not if the protocol says otherwise
<soreau>
why would it permit that
<Company>
because it wants both sides to be able to insist
<immibis>
then the protocol is broken
<immibis>
broken, worth only the paper it's printed on, not fit for purpose,
<Company>
dunno
<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
<soreau>
then you could talk about protocols to put buttons or whatever might be supported by your decorator
<immibis>
the X way as in SSD?
<soreau>
I think the reason why CSD in the first place is because it was easiest from POC POV
<soreau>
immibis: yes
<Company>
no, the reason why csd is why gnome did a huge push for csd 10-15 years ago
<soreau>
I don't think krh made the CSD option because gnome said so
<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
<karolherbst>
I don't think this discussion makes sense to continue if nobody wants to move from their position
<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.
<immibis>
X11 figured out a way for window managers to draw decorations
<soreau>
Company: so do you think gtk will support xdg-decoration or patches would be accepted to support it?
mclasen has joined #wayland
<immibis>
i also read somewhere wayland was originally designed for small systems, like in-car entertainment, where there just aren't decorations.
<Company>
soreau: I looked at it and the main problem is gdk_display_prefers_ssd()
<soreau>
Company: you mean the upfront option?
<Company>
soreau: yeah
<soreau>
I don't really see why you can't just do what other xdg-decoration clients do
<Company>
soreau: other than that, GTK could jsut behave as with kde_decor and send what it does
* mclasen
opens a beer
<soreau>
mclasen: what, didn't bring enough for everyone?
c7s has left #wayland [#wayland]
<Company>
and then once the protocol exists - without any changes to GTK's API - people can propose patches
<Company>
all the MRs that exist in GTK so far were redesigning half of the API while trying to add the protocol
<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
<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?
iconoclasthero has quit [Remote host closed the connection]
<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
<Company>
soreau: like the 3-5 previous attempts
<soreau>
I see
iconoclasthero has joined #wayland
<Company>
I personally only have 1 requirement: GTK apps only need to support 1 method, and for GTK 4, that one method is CSD
<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)
<Company>
for further work, the goal from my pov would be to make it possible for apps to opt-in to SSD somehow
<kchibisov>
Can't gtk always draw CSD when user adds something into decorations and otherwise follow system?
<Company>
and to do things like figuring out if the decoration preferences of the compositor can be used to do things like hide buttons
<soreau>
at least on gtk3, we can choose whether gtk3 apps start with ssd or csd
<Company>
kchibisov: that's kinda how it works on X11 I think
<soreau>
in wayfire
<Company>
kchibisov: but I have no idea if that's implemented on Wayland or if it always uses GTK-provided decorations
<immibis>
I read somewhere GTK only wants to work on GNOME's compositor anyway
vyivel has joined #wayland
<immibis>
they're trying to create a fully integrated ecosystem, no?
<psykose>
this discussion has it all
<kchibisov>
The point is with GTK's decorations is that they carry a lot of buttons.
vyivel has left #wayland [#wayland]
<Company>
GTK apps usually have system decorations next to application buttons
<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.
<Company>
I think the only system button Gnome has by default is close?
<kchibisov>
I think you can adjust it via ipc.
<kchibisov>
but if application designed to rely on decorations, I don't see anything bad in it.
coldfeet has quit [Remote host closed the connection]
rv1sr has quit []
<DemiMarie>
To me, the compositor choosing server-side decorations does not compel the client to stop drawing decorations.
<DemiMarie>
My interpretation is that the compositor will be drawing server-side decorations, and the client is being informed of this fact.
<DemiMarie>
The client is expected to adapt, but how it adapts is entirely client-specific.
<soreau>
well of course the client can draw whatever it wants in its bag of pixels
<DemiMarie>
exactly
<DemiMarie>
I’m not expecting GTK apps to stop having a titlebar.
<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
<DemiMarie>
yup, that’s too strong
<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.
<DemiMarie>
Possibly give some non-normative examples.
<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
<DemiMarie>
There are compositors that must decorate all toplevels.
<soreau>
and that would be easiest for clients to imeplement
<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.
<immibis>
there are windows apps with extra close buttons even though windows always adds a close button (in most cases)
<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.
<Company>
(in Windows the app can do whatever)
<Company>
(that's how Winamp has always worked)
<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
<soreau>
csd just doesn't seem to be a great fit for different toolkits collectively
<soreau>
so it would be nice if toolkits would at least consistently provide the option of ssd
<soreau>
apps shouldn't rely on buttons in the titlebar IMHO
<Company>
from a toolkit pov the best thing is to let the app decide
<Company>
and having a compositor that does whatever the app chooses
<soreau>
well in many ways, this is how it is already
* mclasen
will not listen to 'inconsistent theming' arguments
<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
<soreau>
(following protocol or not)
<Company>
depends
<DemiMarie>
soreau: my compositor won’t bend to the client
<soreau>
DemiMarie: then your compositor seems buggy to your users
<Company>
no decorations are considered application bugs
<Company>
there was a whole Factorio blog post about having to draw decorations because Mutter wouldn't
<DemiMarie>
soreau: no, my compositor will be doing exactly what Qubes OS users not only expect but rely on for security
<mclasen>
then there's no need to argue
<mclasen>
do what you think you gotta do
<DemiMarie>
that said, what I would prefer is a Wayland protocol that everyone can agree on
<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)
<zamundaaa[m]>
But let's not mix the compositor side support discussion with the GTK one, they are pretty separate issues
<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
<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
<DemiMarie>
Company: and the app knows if the compositor draws decorations and can adjust accordingly
<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
<DemiMarie>
Company: is it reasonable to expect the client to stop drawing shadows when SSDs are in use?
<DemiMarie>
Drawing shadows that will just be clipped is a waste of resources and best avoided.
<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
<Company>
for shadows/rounded corners, GTK has different style classes on the window, they just need to be set properly
<Company>
of course, people can write custom themes that do whatever, but GTK proper and Adwaita do what you expect
<DemiMarie>
Company: glad to hear that!
<Company>
but I have no idea if/how that's implemented for Wayland
<Company>
it is implemented for mac OS though
<DemiMarie>
That’s fine.
<Company>
gtk has a mode for tiling/maximized where it doesn't draw shadows (or corners)
<DemiMarie>
Having SSDs enable that should work.
<Company>
there is a bunch of progress possible, but so far nobody was willing to be reasonable, so nothing happened
<DemiMarie>
I hope I am being reasonable here
<Company>
turning that into merge requests that won't be shut down is the hard part
<DemiMarie>
what caused the previous MRs to be closed?
<soreau>
it's easier to just pop a fork and do the expected thing
<karolherbst>
what are the kind of changes people proposed here on the gtk side anyway?
<soreau>
karolherbst: I think Company is saying that only clients should be in control and compositor should obey
<soreau>
but emersion indicated otherwise
<karolherbst>
that's not an answer to my question
<Company>
karolherbst: changes to xdg_decoration or changes to GTK?
<zamundaaa[m]>
karolherbst: support xdg decoration, and when the compositor forces SSD, just hide shadows, rounded corners and ideally the minimize/maximize/close buttons
<soreau>
karolherbst: oh, I must have misunderstood your question
<karolherbst>
the MR proposed to gtk to implement the extension, and what kind of changes they wanted to do
<soreau>
oh
<karolherbst>
so far I got that they tried to change the gtk API, I'm mostly curious to what degree they tried that
<Company>
that's the GTK4 one, there's 2 others for GTK3
vyivel has joined #wayland
Narrat has quit []
<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
<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
<karolherbst>
yeah... CSD vs SSD discussions are rarely the type of discussions to go smoothly in my experience
<mclasen>
there's no pitchforks on my side
<mclasen>
I'm simply not going to accept a protocol implementation that forces ssd on unsuspecting apps
<soreau>
but maybe they should be expecting it
<Company>
yeah
<zamundaaa[m]>
mclasen: SSD is already being forced on these apps
<Company>
but that's the psychological part
<zamundaaa[m]>
Not supporting the protocol doesn't really change what compositors with specific requirements do
<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
<karolherbst>
yeah... you can just be a little nicer than doing thing
<karolherbst>
s/thing/nothing/
<mclasen>
zamundaaa: thats between your compositor and you
<zamundaaa[m]>
mclasen: GTK not supporting the protocol doesn't change that a lot
<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."
<mclasen>
then whats the fuss about ?
<zamundaaa[m]>
But I understand that the situation isn't ideal
<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
<karolherbst>
but anyway...
<karolherbst>
something for you all to figure out
<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
<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?
iconoclasthero has quit [Remote host closed the connection]
<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
glennk has quit [Ping timeout: 480 seconds]
<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)
iconoclasthero has joined #wayland
<Company>
zamundaaa[m]: and then both client and server announce their side, and then you define who in those 5x5 combinations does what
<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
<DemiMarie>
mclasen: not every compositor is capable of that
<zamundaaa[m]>
If the user tells KWin to force SSD, then it'll force SSD
<mclasen>
DemiMarie: I consider your use case to be entirely separate and not really relevant for this dicussion
<DemiMarie>
mclasen: fair
<mclasen>
if your customers require security levels color-coded in window decorations, you gotta do what you gotta do
<soreau>
it's not about whether the compositor is capable, it's about choice, in the end
<karolherbst>
though there are other compositors which also force SSD, e.g. VR ones, no?
<mclasen>
double decorations will be a minor nuisance in that situation
<DemiMarie>
mclasen: would it help to guarantee that `zxdg_decoration_manager_v1.get_toplevel_decoration` has no side effects?
<zamundaaa[m]>
mclasen: the protocol has to cover all reasonable use cases
<Company>
zamundaaa[m]: I think what happens in GTK is that users set a custom "title" widget
<zamundaaa[m]>
Demi's might be a bit out there, but tiling compositord aren't
<Company>
zamundaaa[m]: if they didn't set one, GTK adds its own title on Wayland or switches to SSD on X11
<Company>
zamundaaa[m]: changing that to switch to SSD on Wayland would be one thing you could do
<Company>
zamundaaa[m]: problem: Almost all Adwaita apps set a title widget
<Company>
even gtk-demo does these days
<mclasen>
we do that already
<Company>
do we?
<zamundaaa[m]>
Company: these apps are meant for CSD, right? So that would be fine
<mclasen>
if you you don't set a custom titlebar, ssd works
<mclasen>
at least, it is meant to work
<soreau>
yes it does
<DemiMarie>
Nit: Qubes OS isn’t my project. I’m just the one currently responsible for Wayland and GPU work.
<soreau>
at least at startup
<Company>
I thought it only works on X11, that's neat then
<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
<Company>
the other thing is hiding window buttons - that should be reasonably easy - even in csd apps
<Company>
the question is how you determine that they should be hidden
<zamundaaa[m]>
You hide them when the compositor tells you it's doing SSD
fmuellner has quit [Ping timeout: 480 seconds]
<Company>
yeah, that just requires doing the plumbing
<Company>
currently we don't even track what the compositor does I think - apart from the global preference sent via kde_decor
<Company>
but that setting is global anyway
<zamundaaa[m]>
In kde decoration you don't need to track it, yeah
<Company>
which is the other thing - compositor ssd preference is a global thing in gtk
lsd|2 has joined #wayland
<Company>
because we read that setting from XSettings or dconf in Wayland
<soreau>
well it's also 'read' from the kde protocol from the server on app start
Dami_Lu has quit [Ping timeout: 480 seconds]
<soreau>
Company: because even if you set the 'global' preference to ssd, titlebar widget apps will still have csd, right?
<Company>
yes
<soreau>
hm, don't even honor your own settings :P
<Company>
I don't know what the preference does in detail
<soreau>
smh
<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
Dami_Lu has joined #wayland
<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)
<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
<Company>
it's essentially like a splash screen
<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
<zamundaaa[m]>
Just set whatever state the window had when it was recorded
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #wayland
<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