Back in 2017, a bug report was created on bugzilla asking for ‘Locally Integrated Menus’ like the Unity desktop. This was a feature where the menubar of an app was displayed in the titlebar, appearing on hover by default (though you could make it always visible).
Over the next couple years there was some development, but it was mostly in individual window decorations such as “Material Decoration”. In 2021, there was a merge request made to finally add LIMs into KDE plasma as an option for titlebars. Unfortunately, due to proximity to the release of plasma 6, reliance on x11, and “a technical disagreement over where it should live” [Guido Iodice, @giodice, 2023 comment under merge request], the merge request has had no changes since August 11, 2021.
Personally, I would love to have this feature as it would save a entire menubar’s worth of vertical space on my screen and would allow me to make use of some of the dead space in my titlebars. similar sentiments were expressed throughout the threads under both the bug report and the merge request. many people also talked about giving the option of showing on hover (like unity) or showing always (my preference), and some even suggested making it the default behavior. Do you think this would be a good feature?
@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.
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.
About time for some progress in this.
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.
@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.
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.
@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.
