10:15 wlb: wayland Issue #466 opened by agblacky (agblacky) Some displays freeze after automatic display turn off https://gitlab.freedesktop.org/wayland/wayland/-/issues/466
10:24 wlb: wayland Issue #466 closed \o/ (Some displays freeze after automatic display turn off https://gitlab.freedesktop.org/wayland/wayland/-/issues/466)
15:35 tniin: getting a black screen on Plasma 6 after making a big package update on Arch Linux, using the nvidia proprietary driver, is this a known issue? it worked fine before the update
15:37 danieldg: a kde channel is likely to be more helpful for that problem (or maybe arch)
18:36 TzilTzal: Hi, how do I create a top level window that is styled by the current desktop? I've managed to create a xdg top level surface but there's no decorations at all
18:42 TzilTzal: Hi, how to create a top level window decorated according to the current desktop? I've managed to create a xdg top level surface but there's no decorations
18:44 danieldg: TzilTzal: xdg decoration protocol
18:44 danieldg: if it's not there, then you're running under gnome, which does not believe in server decorations
18:47 TzilTzal: I am indeed in gnome. but when I once tried using x11 and it created a proper window with decorations
18:48 TzilTzal: as a matter of fact when I created the xdg top level surface and buffer it didn't seem like anything changed on the screen. only when I drew into the buffer did I see any changes
18:54 danieldg: TzilTzal: yes, you have to commit a buffer with contents to have anything on the screen
18:54 danieldg: otherwise the size isn't really set
18:55 TzilTzal: I believe it was committed. as said when I painted to it, it showed up on the screen.
18:55 TzilTzal: I guess I'm more interested about the decorations part. are you essentially saying that clients can't create top level windows styled by gnome?
18:56 danieldg: correct
18:56 danieldg: gnome expects you (or rather GTK) to draw it
18:58 TzilTzal: but isn't that a desktop style thing that can be themed? any idea how Qt handles that?
18:59 danieldg: Qt supports the xdg decoration protocol
19:00 danieldg: GTK does the theming via the GTK interfaces (either dconf or some other dbus thing)
19:00 SardemFF7: CSD (Client Side Decoration) is a core Wayland prerequisite, Qt/KDE and a bunch of other DEs/WMs introduced an extension (↑ xdg decoration protocol) to add server-side decoration support
19:06 TzilTzal: what do you mean qt supports the protocol? I'm referring to the client side... I'm creating a window which is what qt does.
19:07 danieldg: when running as a client, qt will draw decorations
19:07 danieldg: kwin (that's still the name of KDE's compositor, right?) supports xdg-decoration and in that case qt will use that.
19:08 llyyr: you can use libdecor for gnome I think, but it's broken and won't follow the system theme
19:09 TzilTzal: when does qt not run as a client? it's used for client side apps no?
19:09 danieldg: TzilTzal: kwin
19:10 TzilTzal: ok that's a kde thing indeed implemented with qt
23:00 mclasen: Company: help me understand some css specs
23:02 mclasen: Company: color spec tells me "currentcolor computes to itself" and "inside the color property, the used value of current color is its inherited value"
23:02 mclasen: the cascade spec tells me that "the inherited value of a property is the computed value of the parent"
23:03 mclasen: so if I set up two styles that have color: currentcolor; and inherit from each other
23:03 mclasen: and interpret these spec fragments, I end up with a used value of "currentcolor" for the child style
23:03 mclasen: which doesn't exactly tell me how to draw
23:05 mclasen: browsers seem to gloss over that and inherit the used value from the parent insetad
23:07 mclasen: arr, sorry, wrong channel
23:13 emilio[m]: mclasen: not sure what the right channel is, but per spec you're supposed to go through all the parent chain yadda yadda. In practice we cheat and for color only resolve currentcolor early: https://searchfox.org/mozilla-central/rev/9a83c0336f00635d8253ca920d3319c6936cde12/servo/components/style/values/specified/color.rs#838
23:14 mclasen: yes, sure, you need to go through parents
23:14 mclasen: but the specs are just inconsistent
23:16 emilio[m]: mclasen: How so? The "two styles inheriting from each other" is not something that can happen, and the initial value of the color property is not "currentColor"
23:17 mclasen: where does the inherited value come from, if not from some other style ?
23:20 emilio[m]: Ah sorry I understood you were forming some sort of weird inheritance cycle. But my point is all inheritance chains should start at the initial style, which has an absolute color, so there's no cycle
23:20 mclasen: but it doesn't matter where they start. It only matters where the 'inherited value' comes from
23:21 mclasen: the spec says it is "the computed value of the property on the parent"
23:22 mclasen: so you're telling me if browsers see that the value on the parent is currentcolor, they just inherit from the grandparent
23:22 mclasen: that trick maybe works in css2
23:23 mclasen: but what do you do if the inherited value is color-mix(in srgb, currentcolor, black) ?