 is not only gearing up for a big technological shift, but is also adding cool new features and improving the user experience](https://cdn.masto.host/floss/media_attachments/files/110/796/930/641/437/135/original/e69c4c710545b583.png){kind=link}
This week in KDE: #Plasma6 is not only gearing up for a big technological shift, but is also adding cool new features and improving the user experience
Look forward to sound themes! Snappier responses! Prettier widgets! More awesome things!
https://pointieststick.com/2023/07/28/this-week-in-kde-sounds-like-plasma-6/
…I’m not sure what I’m looking at.
I’m not sure if you are suggesting Developers need to keep 4 different layouts in mind, or if I’m not getting the mockup.
It’s like the content of the window could “leak” into the title bar
If you enable CSD in Firefox you can already merge the tabs with the window controls
Alright, so here’s the issue:
Is the content that is allowed to leak into the title bar configurable by the user? For instance, could I only allow Tabs to be merged and keep the buttons outside the title bar?
If Yes: Now the dev has to figure out different ways to make the app look good for a bunch of weird configurations. For instance, in your mockup you have a three dot button on the first picture, but not on the second. If a user doesn’t allow the 3 dot button to leak into the title bar, the dev has to place the function of that button elsewhere.
If no: You haven’t solved anything, have you? This is just Firefox, which already exists. I can already control if Firefox uses CSD or not. What is the point here?
Me and the other person here are trying to make you understand that CSD doesn’t imply GNOME’s header bar.
Some applications could take advantage of CSD without the user even noticing if they are looking at a SSD or CSD app.
CSD vs SSD is just a technical implementation with the difference that the SSD draws a line inside a window: the window manager is responsible for what is above the line (the title bar) and the app for what is below the line.
With CSD that line just doesn’t exist.
I know that, the question is why. The discussion started with a user asking for talks about Plasma going with Client Side Decorations in the future. To which I say: No.
A header bar is the logical conclusion of CSD, because it makes sense once you give window decoration responsibilities to app devs. That is space that the dev can use to cram buttons and other features, why wouldn’t they use it?
While KDE could create documentation that suggest using CSD in a way that looks similar to the current title bars, that is more what you’d call guidelines than actual rules. It is not the great equalizer that SSD is. If an app uses SSD, there is no question on whether the Title Bar will look good, it will look the way it is supposed to, no wondering if the developer implemented the design in the correct manner. With CSD, the dev could not have followed KDE’s guidelines, and even then, there is the question of what to do when you are not in Plasma. Should an app made with KDE Guidelines in mind make changes to its CSD when it runs on GNOME? Some GNOME apps don’t, should it be mutual?
And that is not even to mention the idea of using CSD to look like it is SSD. Again, you are trusting the app dev to make something that is currently taken care by the system. It doesn’t really makes any sense, you are adding another point of failure.
In some cases a SSD title bar is just a waste of space.
And you can remove them using window rules. You can’t remove a CSD title bar, or even add one, trust me, I tried.
Removing the whole title bar implies no window buttons, the point is having them while not wasting space.
As I already shown to you GTK apps display window controls according to a global config. So you can turn a header bar in just a toolbar. I don’t know about other CSD apps but it would be their fault, not a CSD disadvantage.
One reply ago you were fine with apps hiding the close button.
You really can’t, I tried using gtk3-nocsd and it didn’t really work that well