Bug 425874

Summary:	Shorter titlebar (without smaller font) option needed: less padding
Product:	[Plasma] Oxygen	Reporter:	Duncan <1i5t5.duncan>
Component:	win deco	Assignee:	Unassigned bugs mailing-list <unassigned-bugs>
Status:	REPORTED ---
Severity:	wishlist
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Other
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	oxygen titlebar negative vmargins demo hack-patch testing only tiny titlebar button option patch

Description Duncan 2020-08-27 13:57:28 UTC

So this is a follow-on to bug #425864, an aurorae-based windecos bug.  As I worked on that bug I realized once again the reason I was running an aurorae-based windeco in the first place -- I needed a relatively short-height titlebar without forcing the font to microscopic in ordered to get it.  Put differently, oxygen and breeze are both far too empty-space vertical-padding-heavy for users who like titlebars but don't want to /waste/ space, with no option other than hacking the code itself to reduce padding to something reasonable for a minimal-height titlebar just tall enough to fit the chosen font size.

Years ago I found an aurorae-based windeco (black square) on kde-look that was quite close to what I wanted/needed, and being aurorae-based, finding and editing the height to cut just a couple extra pixels was relatively simple.  While aurorae-based did mean it lacked some of the fancy options that breeze and oxygen had, it did what I needed and worked fine for years... until my distro (Gentoo) decided to switch to libglvnd for automatic handling of the opengl driver, thus triggering the unfortunate 100% transparent titlebars bug with aurorae-based windecos I just mentioned, above.

It turned out that neither the oxygen nor breeze windecos had that bug, but they still had the horribly fat vertical-padding issue that had driven me to looking for alternatives on the then kde-look in the first place, alternatives that were almost all aurorae-based.

So here I am filing this bug, wanting some option to reduce the vertical padding for oxygen/breeze, so I can get back those fancy titlebar effects without wasting all that empty space real window content can put to better use!

Now I'm running gentoo so build from sources all the time, and for kde-frameworks/plasma/apps I run the live-git versions from the gentoo/kde overlay and regularly bisect and file bugs, etc.  So applying patches locally isn't a big deal, and while I'm not a dev, occasionally, especially when pointed at the right place by a commit, I can modify or create my own patches that do what I want to do.

In this case I didn't have commits to point my way, but finding where and patching Oxygen to "reduce the fat" turned out to be far easier as a git-literate advanced gentooer but never-the-less non-dev, than figuring out how to patch aurorae to fix the bug with it!  So that's what I did, I hack-patched oxygen, reducing the titlebar vertical padding so I could have a reasonably sized actually readable font (8pt Noto Sans)... and still limit my titlebars to the 15 px high I was using on black-square with the same font!  I knew was possible because I /did/ have black-square doing it, and after a long day of hack-patching, I finally had the oxygen windeco doing the same thing.  By contrast, without the patches even the absolute minimum and totally unreadable 4 pt font size was heavier weight height-wise, and anything readable was effectively double the height, 30 px or more!

A couple days later, to my surprise, I found that the hack-patches I had only applied to oxygen reduced the fat-padding on breeze as well, and it too could now handle 8 pt Noto Sans titlebar fonts at 15 px titlebar height.

Now these are only hack-patches; I'm not a dev and don't-know-how/didn't-bother-to-try-to-figure-out-how, to setup proper padding options.  But I figure if I found these useful enough to spend 12-hours plus reading and experimentally hack-patching to get it to work, surely, there's others out there that could use the same features I hack-patched, especially if all they have to do is spend a few seconds to select an option to get them.

So that's what I'm asking for, the option.  I'll upload my hack-patches so you can see exactly what I changed, and hopefully, proper patches to do the same thing with options aren't too much trouble, and don't violate the guidelines badly enough that they can't at least be made options.

Else if it's simply too far out of policy, now that I have the hack-patches I can keep hack-patching for my own needs with little further trouble, any maintenance will after all have git commits pointing the way, unlike these initial hack-patches, but surely, some others will find the option useful, if it's there for them to find at all. =:^)

See also bug #418904 (filed by someone else), but that's style/widgets not titlebar/windeco.

Demo hack-patches to come, but it's a few days after my 12+ hour hackathon, and on pre-posting second-look I decided I've a couple further small tweaks to test and comments to tweak, first.

Comment 1 Christoph Feck 2020-08-27 14:17:10 UTC

Does it help to reduce the button size?

Comment 2 Duncan 2020-08-27 15:52:27 UTC

Forgot to mention, all my scaling is 1.0 (on X, obviously).  I do /not/ have font-dpi forced but the xorg log says it's the standard 96x96. 

(Actual physical is dual 4k 75-inch TV-monitors, ~59 dpi according to the online calculator I just googled on ddg.  Yes, I'm fighting for that titlebar height even with that sort of screen real estate to work with, as I typically have a video full-screen on one monitor and divide the other into a 2x2 window grid of 1730x1080 px windows with the remainder a gkrelm sysmon.  RIP superkaramba.  And 15 vs 30 px off the 1080 height of a single standard grid-window is still a big deal, even if that 1080 height is ~18 inches on-screen (with the 15 missing px being a measurable quarter inch!).)

(In reply to Christoph Feck from comment #1)
> Does it help to reduce the button size?

I was using small size, the smallest possible choice, already.  My first hack-patch  added a tiny (*1.0) option, which did reduce size some, but not enough.

So I attacked the padding, and after that I could actually set button size back to /normal/, actually /increasing/ it from small, without increasing the titlebar height.  (I think it might have increased it 1 px for normal, but I was OK with that for the full-size button tradeoff, knowing I could always go back to small if I decided to.

Once the padding was gone, tiny buttons aka *1.0 was /ridiculously/ tiny, /much/ tinier than either the font or the titlebar (the emblems inside were about the same size as the font was when I tried 4 pt font, unreadable), so it wasn't worth it.  As I said, even normal was basically titlebar height, with the existing small below that, so tiny simply wasn't useful.

But while I'm actually running normal button size ATM but with the tiny option still in the menu as I didn't actually move that patch out of my auto-patch dir, I'm still throwing in actually removing it from auto-patch as one of the pre-posting tests, just in case my tiny-button addition had some other effect and without it the small size is suddenly much bigger or something.  Literally just moved it out for the test when I saw your reply popup in email, matter-of-fact.

Comment 3 Duncan 2020-08-27 22:31:56 UTC

Created attachment 131226 [details]
oxygen titlebar negative vmargins demo hack-patch

Glad I took the time for a second look.  A lot more made sense this time thru and I ended up dropping one patch entirely as unnecessary, and making another basically test-time only.

This is the main idea here.

At the given negative 2 TitleBar_TopMargin and -1 TitleBar_BottomMargin settings it squeezes things slightly on the Noto Sans Medium font, normally no exotic (aka mostly ASCII) characters common in my titlebar here.  It's likely to be worse for Asian charactersets and the like, and as such it's likely to be the lower bound.

Zeroing out both values (along with TitleBar_OutlineMargin, already zeroed out here) would yield a somewhat less vertically squeezed titlebar that if I'm understanding the call to qt font-functions the metrics are based on correctly, should just fit maximum font ascenders and descenders even for non-western characters.  Zeroed values resulted in a 16px high titlebar at 8pt font I was working with.

But the results for the negative values as posted are even better than I expected, a 10px high titlebar at the 8pt font size I was working with.  That allowed me to increase the font to 10pt for 14px high.  I'll have to play a bit more to see whether I prefer the extra 4px I get at 8pt font or the somewhat more comfortable to read 10pt.  (9pt was the same 14px high titlebar as 10pt, while 11pt increase it to 17px.  So 8pt and 10pt are the practical choices.)

Would be cool if I could do the option UI too but that's beyond me ATM.  Assuming it's implemented, maybe I can learn from the commit adding it...

There's another minor testing-only patch coming too, adding a tiny button size, but it didn't reduce the titlebar size so I consider it only practical for testing.

Comment 4 Duncan 2020-08-27 22:42:25 UTC

Created attachment 131227 [details]
testing only tiny titlebar button option patch

While this patch didn't end up giving me a vertically shorter titlebar, but it's useful for testing, with the tiny titlebar button option it offers helping to ensure it's not the button size controlling the titlebar height, just the font size.

(Actually, being the first hack I tried it did give me a smaller than default titlebar, but not small enough.  Clearly it was the font padding I had to attack.  And after I did so I could actually choose the existing small or normal button sizes without increasing titlebar height, so this patch was no longer of much use except to ensure the buttons did not interfere with testing the padding patch.)