101
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
(cdn.masto.host)
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/
@kde@floss.social @kde@lemmy.kde.social but no room for a new talk about going with client side decorations? π₯Ί
Why would you want to ruin Plasma?
@ChristianWS How would that ruin Plasma?
We are talking about CSD, are we not?
There are quite a number of DEs using CSD, and a couple of them even feature a more "traditional" layout with a button panel and left side app menu.
While some folks like it, at this point one of the defining features of Plasma is the fact that it stands out by not using Server Side Decorations, or GTK for that matter.
~~Besides, CSD is ugly~~
@ChristianWS CSD can just look like the normal Window+Decoration.
My point is however that KDE can use it to at least put something to the CSD, like the app-menu if visible. Different apps would find different purposes for it and there shouldnt be a hard requirement for it, but optional feature to use for the devs.
CSD is just a ugly as you make it to be. In my opinion SSD is nowadays very out of place, vertical wasted space.
Not really following what you mean.
The moment you allow CSD, apps can and will put whatever they want on there, leading to wildly inconsistency in the number of things there.
CSD will always looks weird cause it takes too much vertical space. It will never look as good as a normal Title Bar, which can be controlled by the server.
You also lose draggable space, as now buttons are taking space.
@ChristianWS It's not the app that does this. Developer do this, they do this because they think it's good. The KDE does have a nice visual design group (I was once part of it, So I know :P). It would be possible to define a design guide to follow so apps won't look out of place, while still are able to make use of CSD.
Plasma doesnt need to look like GNOMEs implementation of a CSD. The visuals are a completely different thing. The technology is the important part at first.
Design follows technology and vice-versa. Once you allow devs to use CSD they can and will use that space to put buttons on it, and that inevitably leads to inconsistency between apps, because they will never share the same amount of buttons or be divided by the same amount of panels.
CSD is a Pandora's box that is best left unopened.
@ChristianWS "Design follows technology and vice-versa." Thats a hard one. Yes, and also no. Things dont need to be the same to behave the same. Take Firefox and Chrome. They do not look the same, they still behave the same. They share a common design guideline. You need to go to the settings to see the parts that differ.
If KDE provides a good design guideline devs would follow them, because it's easier and faster to have working patterns instead of putting work into it yourself.
It doesn't work for CSD cause you either have a very strict guideline to prevent inconsistency, limiting the number and location of buttons. At which point it is so limiting that Developers need add another bar to hold whatever they can't put on the header bar, rendering the CSD implementation moot.
Or you do like GTK and allow inconsistency. You can't win with CSD.
And that is not even mentioning if CSD is even a good idea in the first place. Some users deliberately went with Plasma due to the lack of CSD in the first place, those would migrate to LXQT or XFCE.
@ChristianWS I think your idea of inconsistency differs from mine. Havin buttons on different locations in a headerbar doesnt have to be inconsistent across apps. Different layouts can be consistent.
BUT I dont talk about header bars. I do talk about CSD only and they can be whatever a guideline makes them to be. All Qt apps already have a CSD, but they suck and it would be nice if app devs would be allowed to make use of them on the KDE side if they decide that it benefits the app.
I'm genuinely curious: What exactly do you have in mind with CSDs without the use of a Header Bar?
CSD and Header Bars are practically synonymous, and I don't think I've seen, or even heard, about CSDs without the context of a header bar
@ChristianWS depending on the application different things. Like I said before, the visuals, the design is not what I care about right now. It's the option to have another talk about that topic in general.
Last time, there was no focus on wayland and there wasnt much experience with CSD in general. There also was the proposal of DWDΒΉ as option, that never came up.
1: https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candidate-for-kde-window-decorations/
...how do you hope to have a discussion about a design feature without discussing the visuals? The entire CSD vs SSD debate is one of UX/UI Design
You still haven't provided an example of CSD without a Header bar. I'm familiar with the DWD proposal, the technology used might be different, but the end result is still a Header Bar in all but name.
@ChristianWS Huh? I have shown 3 pictures of a CSD without header bar (Nextcloud, Blender, Gimp).
CSD vs SSD is about control and integration. CSD can just look like SSD, thats why I do not care about the visuals.
...where? No seriously, I don't see any picture, there's only the link to DWD. I don't use Nextcloud, but both Blender and Gimp use SSD on my system.
And I'm quite confused by the idea of CSD looking like SSD. I know it can, however, I don't see how that isn't an argument for continuing to use SSD. 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?
> 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.
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
It was another person.
Again, you are confusing the concept of CSD with GTK's implementation of CSD.
I give up, cheers.
@ChristianWS In this post: https://mstdn.social/@fabiscafe/110803301092316008
XDG-decoration is not a core part of Wayland. So there is no guarantee that the compositor your user runs does support this. So the general improvement would at least be that you dont have to test both.ΒΉ
On top of that the app could have more control over it's decoration, for accessiblity stuff. Like going in a OLED/e-Ink/High-contrast mode.
1: https://wayland.app/protocols/xdg-decoration-unstable-v1
...you sure the pictures aren't an argument against CSD? The wallpaper on those pics looks the same, so I'm assuming they are on the same system, but they are inconsistent with one another. Meanwhile Blender and Gimp on my system look right at home.
...ain't that supposed to be part of the window manager tho?
@ChristianWS There are 2 consistencies: Consistent to the system and consistent to the application.
I prefer consistent to the application, because I think the application developer is more capable to kow what the app needs then the general window decoration provider is.
π§΅οΈβ¦
...yes, I agree with that, and that is why SSDs are superior. They allow the app developer to do whatever they want inside the app, while also making sure the window frame is consistent with the rest of the system.
It's like a gallery wall in a home, you can mix photos and paintings with varying styles, and they would still look like they fit together if you use the same frame style on them.
@ChristianWS What if the application developer needs more? Hide the close button, unallow to minimize, display an exit button on fullscreen, Transform the whole app design on the fly or just to have a dark design for the application including decoration (This one hurts my eyes extremly for krita on windows π₯²οΈ). SSD is just not flexible and might not even provide the feature set required by an application.
Thats why it would be nice to give them the option to implement it directly.
I mean, disabling the close button is probably on the top 10 ways to give a PC user a panic attack. And there was a time when games had an exit button on fullscreen.
Also, what the hell, if Undertale can jumpscare the player while still using Windows titlebar on display then SSDs are not an issue.
@ChristianWS And yes, this is only the current, very early state. Libdecor is will have theming support to have an option to look "system design native" (Blender) and for Gimp, this is experimental on an pre-release. Qt on the other hand, I assume, probably doesnt care right now, because the apps that use Qt and matter come with an own design language and own CSD anyways and everything else is probably not worth the work for basically linux wayland only.
As shown by Latte Dock's Window Buttons widget, apps can display window controls that follow the window decoration theme.
And in GNOME apps follow some guidelines that include how header bars should be.
KDE apps do the same for everything but the titlebar that is drawn by KWin. If they are consistent with their content, I don't see why they wouldn't stay consistent when making the titlebar/window controls their own responsability.
I don't understand the Latte Dock argument.
And I was having GNOME in mind as the example of the inconsistency natural to CSD.
Latte Dock:
https://psifidotos.blogspot.com/2020/04/article-rounded-plasma-and-qt-csds.html
GNOME official apps the the "Circle" ones look very consistent to me:
https://circle.gnome.org/
I don't understand the Latte Dock argument because it is only relevant to the window buttons, there is still the rest of the header bar.
I picked some random apps in the "Circle" and all of them are inconsistent, I don't understand. They have inconsistent number of buttons, placement, and organization
These are guidelines for header bars:
https://developer.gnome.org/hig/patterns/containers/header-bars.html
Yes different applications feature a different set of controls but in a consistent way, just like the rest of the UI. I don't understand why you expect a portion of UI to be exactly the same for all apps.
It is definitely not consistent, even when they have the same buttons.
AudioSharing has the hamburguer button on the left side, while Decoder has on the right side.
Citations has the header bar split to follow the panels inside the app, where Boatswain is divided into two panels, but the header bar isn't.
And that is not to mention how some apps style the header bar itself, but I'm going to assume it is a problem with the screenshots not being taken on the same system.
I don't want to be mean to GNOME, as KDE is also guilty of this and both are built by maintainers, but the GNOME Guidelines is bare bones. It offers too little information on the best practices and what should be done. It is a totally not-fair comparison, but compare it with the Top App Bar Component guideline of Material Design, and yet it is still not enough as it overlooks some common edge cases.
About the hamburger menu: are those screenshots by you or by diffetent people from the Web? Because the position of the menu is a user setting:
https://docs.gtk.org/gtk4/property.Settings.gtk-decoration-layout.html
About the split of header bar: it depends if an app has a header bar that refers to both the views below or the app is splitted in two with two header bars that refer to the respective views.
...they are all taken from the GNOME Circle website you linked, the first screenshot of each app
And if you install them they will follow whatever global setting you have, consistently.
Sorry for assuming you were familiar with GNOME/GTK.
Oh, I definitely don't, I did go out of my way to purge header bar apps from my system. The last one was Flatseal, but KDE integrated most of the options into system settings. I still do have some CSD apps, but they are either used full screen non-stop, like Firefox, or rarely used.
Huh, you are right. It is weirdly harder to figure out the person I'm replying to depending on the platform I'm using.