Bug 512613 - Excessive padding on the left of context menu items
Summary: Excessive padding on the left of context menu items
Status: RESOLVED INTENTIONAL
Alias: None
Product: Breeze
Classification: Plasma
Component: general (other bugs)
Version First Reported In: 6.5.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-11-25 22:05 UTC by Damglador
Modified: 2025-11-26 00:57 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
Example (16.12 KB, image/png)
2025-11-25 22:05 UTC, Damglador
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Damglador 2025-11-25 22:05:18 UTC
Created attachment 187174 [details]
Example

SUMMARY
With the new Breeze update [1], some padding was in context menus at the top, bottom and on the left of items. The padding on the left stands out too much, especially in context menus with low amount of items and without text on separators. 

STEPS TO REPRODUCE
1. Open Dolphin
2. Right click on something

OBSERVED RESULT
Padding on the left is excessive

EXPECTED RESULT
Something closer to padding on the top/bottom would be nicer

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.5.3
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.0
Kernel Version: 6.17.8-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 5600H with Radeon Graphics
Memory: 16 GiB of RAM (13.5 GiB usable)
Graphics Processor 1: AMD Radeon Graphics
Graphics Processor 2: NVIDIA GeForce RTX 3060 Laptop GPU

ADDITIONAL INFORMATION
[1] https://invent.kde.org/plasma/breeze/-/merge_requests/563 (and fixes to it)
This is NOT a duplicate of https://bugs.kde.org/show_bug.cgi?id=512363
Comment 1 Roke Julian Lockhart Beedell 2025-11-25 22:41:55 UTC
I agree. This, coincided with reduced padding between the icons and their text, makes what once seemed balanced (and was much closer to balanced, on all sides) appear uniquely difficult to parse. I'll note that I don't observe this arrangement on any other DEs and OSes; instead, they all attempt to imitate < 6.5.3.

For anyone unfamiliar with this topic, see https://www.reddit.com/r/kde/comments/1p3jacn/comment/nqs2ja0/.
Comment 2 David Edmundson 2025-11-26 00:03:54 UTC
The new version looks better and is more consistent with other menus.

Whilst I understand that change looks odd at first there is a cost to having options and at the end of the day no-one spends that long looking at menus.
Comment 3 Damglador 2025-11-26 00:05:22 UTC
Then other menus should be changed as well. These menus are everywhere, not looking at them is impossible.
Comment 4 Damglador 2025-11-26 00:13:03 UTC
It looks too big even compared to padding on the right, if looking at the arrows (if present), with ~14 pixels from the edge, compared to ~18 pixels on the left.
Comment 5 Roke Julian Lockhart Beedell 2025-11-26 00:57:00 UTC
(In reply to David Edmundson from comment #2)

> The new version looks better and is more consistent with other menus.

Can you really close it with “looks better” when others clearly disagree? I don't know how to empirically determine which is superior, but I know that that kind of dismissal doesn't assist much.

We're all for consistency. That does not mean that we all want the design decisions present in Kirigami's QQuickStyle to be authoritative, especially over the long-beautiful QWidgets QStyle.

> Whilst I understand that change looks odd at first there is a cost to having
> options and at the end of the day no-one spends that long looking at menus.

That's not a reason not to improve something, else this change wouldn't have occurred.