About time for some progress in this.
this post was submitted on 14 Jan 2025
23 points (100.0% liked)
KDE
5715 readers
179 users here now
KDE is an international technology team creating user-friendly free and open source software for desktop and portable computing. KDE’s software runs on GNU/Linux, BSD and other operating systems, including Windows.
Plasma 6 Bugs
If you encounter a bug, proceed to https://bugs.kde.org/, check whether it has been reported.
If it hasn't, report it yourself.
PLEASE THINK CAREFULLY BEFORE POSTING HERE.
Developers do not look for reports on social media, so they will not see it and all it does is clutter up the feed.
founded 2 years ago
MODERATORS
Url link and text is reversed.
should be fixed now
looks fine on my end, just a link In the middle of the sentence.
Try clicking the URLs.
I've never really used links like that since I switched to this platform, I'll fix it when I get home.
@unknown1234_5 This would be amazing.
right? I'm hoping that this post gets it enough attention to get someone who knows what they're doing to finish it so I can have it.
KDE has always favoured SSD over CSD. So it kind of makes sense that LIM was rejected.
https://blog.martin-graesslin.com/blog/2013/02/client-side-window-decorations-and-wayland/
Aesthetically, I think CSD is the way to go. But functionally, I love KDE too much to use anything else.
I don't know what SSD and CSD are
SSD: Server Side Decorations
CSD: Client Side Decorations
It’s how kwin fundamentally works. And why you can’t just have application specific buttons and widgets in kwin window decorations like how in Gnome you can.
The article I linked is from 2013. They’ve been discussing this for a long time.
LIMs should be possible, the application menu (hamburger menu) titlebar button already does half of what's needed. it's also already been done before and just needs to be updated to plasma 6.
I imagine the code is not the problem, but more of a philosophical one. I am on your side that this is sorely needed in KDE. But I’ve been seeing KDE devs shoot down this type of functionality for a decade now and the state of this MR looks like more of the same.
from my reading of it, it seems like the thing that kept it from being merged 3 years ago was some disagreement on what system component should be in charge of it (at the time it worked) and what is keeping it now is that it was made for plasma 5.9 (putting it some 700 or so commits behind where it needs to be).
also, I don't really see how this would be any more "client side" than the hamburger menu titlebar button already is. it's just a longer button (or set of buttons, technically), however long it needs to be for the number of options it has.
This sounds new to me and I'm curious, how does this menu fit in a small window if it has many options? Is it horizontally scrollable somehow? Does it block the user from making a window smaller than the width of all menu options?
most of the discussion about that said to collapse it into a hamburger menu. my preference would be to scroll.
@quaff @unknown1234_5 Aesthetics is a matter of opinion and I disagree with you. I think crowded title bars, each in a different way, don’t look good.
KDE was always configurable so I wonder if it’s possible (and how hard is it) to handle both depending on configuration… 🤔
well obviously this would be an option and not a requirement (like the existing app menu titlebar button and panel widget, as well as the global menu widget.). there was some discussion of it being the default but I don't think it should be because I agree that crowded titlebars don't look that good. regardless, I think it should be an option because it gives people more control over the usage of space on there screen.
@unknown1234_5 And then you have no place to click on the title bar to move or maximize the window.
No.
well first, it'd be optional like everything else in the titlebar. second, meta+left click and meta+right click for moving and resizing respectively. third, it doesn't have to take up the whole titlebar, and most apps don't have enough options for it to do that anyway.
@unknown1234_5 All is true but I'm still not convinced. As you wrote, "most apps" and "doesn't have to". All these mean it will happen in some cases that you have to press a Meta key to do things you were supposed to be able to do with just your mouse.
yeah, but you could always use a spacer to reserve some space or change what parts of an app are draggable. you also could simply not use this feature. that way whoever wants this feature has it and everyone else can continue to not care about it, like most of the options in any software.
edit: typed the instead of that, fixed it.