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/
> What is the benefit of changing from SSD to CSD if the end result is to look like SSD, but have all the issues that come from using CSD?
Because you can implement things like these (open this comment in Mastodon if in Lemmy you don’t see the attached images) and I don’t see what the issues are:
Yeah, I have no idea what is going on
https://pkm.social/@alexl/110804381069988483
…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.