KDE

5613 readers

80 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

carlschwan@lemmy.kde.social

Bro666@lemmy.kde.social

herzenschein@pawb.social

Aniqakhokhar@lemmy.kde.social

'Locally Integrated menus' in KDE (kbin.earth)

submitted 4 days ago by unknown1234_5@kbin.earth to c/kde@lemmy.kde.social

22 comments fedilink hide all child comments

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?

you are viewing a single comment's thread
view the rest of the comments

[–] quaff@lemmy.ca 1 points 4 days ago (2 children)

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.

[–] aemstuz@pol.social 1 points 14 hours ago (1 children)

@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… 🤔

[–] unknown1234_5@kbin.earth 1 points 2 hours ago

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@kbin.earth 3 points 4 days ago (1 children)

I don't know what SSD and CSD are

[–] quaff@lemmy.ca 3 points 4 days ago (1 children)

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.

[–] unknown1234_5@kbin.earth 2 points 4 days ago (1 children)

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.

[–] quaff@lemmy.ca 1 points 4 days ago (1 children)

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.

[–] unknown1234_5@kbin.earth 1 points 4 days ago (1 children)

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.

[–] vort3@lemmy.ml 2 points 15 hours ago (1 children)

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?

[–] unknown1234_5@kbin.earth 1 points 2 hours ago

most of the discussion about that said to collapse it into a hamburger menu. my preference would be to scroll.