Open Bug 1833124 Opened 1 year ago Updated 1 year ago

Consider bringing back -moz-gtk-csd-menu-radius for better OS integration, with special handling of Breeze theme

Categories

(Core :: Widget: Gtk, enhancement)

All
Linux
enhancement

Tracking

()

People

(Reporter: dao, Unassigned)

References

Details

From https://phabricator.services.mozilla.com/D177369#inline-982287:

Same here, I understand it won't be perfect but I don't quite understand why matching the native theme more closely wouldn't be better from the user's perspective.

I guess my point is that our menus aren't really native and, in general, I believe the menu border radius is not a super-valuable customization to have, given the workarounds it'd require (see below). In particular I think making Breeze look good is a requirement, because it's the default KDE theme.

Same here, yes, we'd force a dynamic radius on menuitems, but how's that worse than forcing a fixed one? Is the number we get via gtk3 for popups totally off base compared to gtk4?

Yeah, that's the crux of the issue I guess. For the obvious example I know, the gtk3 Breeze theme (which is the default KDE theme) has a 2px menu radius, while gtk4 apps have a radius that's closer to our current menus. I guess we could special-case as needed for some well known themes.

(In general, it seems to me that the Linux theming stuff is moving more towards less in-depth theming, more based in the color-scheme, which is pretty much what we do with our popups, see https://github.com/flatpak/xdg-desktop-portal/pull/815 / https://stopthemingmy.app/, etc.)

Anyways, again, happy to keep the env var if you insist and you want to deal with that, but without uses for now to avoid changing behavior in this patch.

Note that the padding issue noted earlier in that comment has been addressed in bug 1832549.

See Also: → 1708835
Duplicate of this bug: 1838433
You need to log in before you can comment on or make changes to this bug.