[RFC] Increase default font sizes by 1 pt
AbandonedPublic

Authored by ngraham on Aug 15 2018, 9:04 PM.

Details

Reviewers
valorie
Group Reviewers
Plasma
KDE Applications
VDG
Summary

We discussed the idea of increasing the font sizes by 1 pt at the VDG BoF at this year's Akademy and folks seemed okay-ish with the idea, so I thought I'd put it in patch form to continue the conversation.

This change would yield improved readability for text: in addition to just being larger, Noto looks significantly sharper and more substantial at 11pt than it does at 10pt, especially with a non-hi-dpi screen (most users still have fairly low dpi screens). And the default 9pt Hack for the Fixed Width font is just really really small and hard to read; 10pt is much easier. Same with the Small font, which goes from 8 to 9. Overall, text seems more readable.

It's notable that all other desktop operating systems use at least 11pt as the size of their UI font, and some go much larger. The experiment has already been done for us and the results appear to have been positive judging by the fact that everyone else made the jump to 11pt UI font size. Perhaps we should too.

Downsides:

  • Reduced text density (obviously)
  • Some UI elements become larger, reducing overall screen density. It's particularly noticeable with Kickoff and the Task Manager. Are we willing to live with that, or should we investigate whether or nor that kind of scaling should happen? There are also some widgets like the System Tray whose icons become spaced very slightly farther apart for basically no reason (there's no text). Is this a bug we should fix?

It's worth reiterating that this is simply a change of defaults; programmers and pepople under 25 who have perfect eyesight can always reduce the font sizes to increase the on-screen density. But I think it's worth revisiting whether this is the group of people who want to optimize the text for by default.

Test Plan

Examples:
Before:

After:

Before:

After:

Diff Detail

Repository
R119 Plasma Desktop
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 1884
Build 1902: arc lint + arc unit
ngraham created this revision.Aug 15 2018, 9:04 PM
Restricted Application added a project: Plasma. · View Herald TranscriptAug 15 2018, 9:04 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
ngraham requested review of this revision.Aug 15 2018, 9:04 PM
ngraham edited the summary of this revision. (Show Details)Aug 15 2018, 9:07 PM
ngraham edited the test plan for this revision. (Show Details)
ngraham added a reviewer: valorie.
ngraham added a reviewer: VDG.

Honestly if you look at the last before and after shot the text now looks worse then when it was 10 pt. I think the issue is more your hinting then the font size.

This isn't the only place this needs changing, but we can sort that out if/when the concept gets accepted.

abetts added a subscriber: abetts.Aug 15 2018, 9:57 PM

I like the way this looks, I would like to push it further for clarity and ask for window title at 13 and bold. I feel people stand to benefit from seeing a window title that is readable, especially when we have a dark color background default.

I like the way this looks, I would like to push it further for clarity and ask for window title at 13 and bold. I feel people stand to benefit from seeing a window title that is readable, especially when we have a dark color background default.

Here's how that would look with a comparison.

11pt title:

13pt title:

To me that looks way too heavy and attention-getting. Here's 13pt non-bold:

Or even 11pt bold:

I actually really like 11 pt bold for the title.

I think the issue is more your hinting then the font size.

11pt does look even better when the hinting is appropriate (slight RGB hinting for most people), which is fixed by D12925: Parse global config files. Remove 'Vendor default' option. Fix changes not recognized.. But that's not really related to this. The idea of making the size bigger is to increase readability, which is just something that naturally comes from having the text be bigger; this is not controversial. The question is not whether larger text is more readable (it is), it's whether or not it's worth it because of the trade-offs involved.

The title bar with the bold font looks nice at both sizes.

Reduced text density (obviously)

Our defaults are not very dense so the loss of density is only going to be bad, except for the case of small screens. On those its more then reasonable to assume you will need to adjust your fonts and the sizes of things in general anyway.

Some UI elements become larger, reducing overall screen density. It's particularly noticeable with Kickoff and the Task Manager. Are we willing to live with that, or should we investigate whether or nor that kind of scaling should happen?

To try to figure out how much larger things will be with these new defaults for the fonts I used gimp's scale tool with the provided images. Its looking like the average element will be 10% larger with the bump up in font size. This should effect any element that has text, all qlabels without text and anything using Font Metrics.

There are also some widgets like the System Tray whose icons become spaced very slightly farther apart for basically no reason (there's no text). Is this a bug we should fix?

Yes, We should look into why these widgets are acting that way.

I like the way this looks, I would like to push it further for clarity and ask for window title at 13 and bold. I feel people stand to benefit from seeing a window title that is readable, especially when we have a dark color background default.

Here's how that would look with a comparison.

11pt title:

13pt title:

To me that looks way too heavy and attention-getting. Here's 13pt non-bold:

Or even 11pt bold:

I actually really like 11 pt bold for the title.

I think the issue is more your hinting then the font size.

11pt does look even better when the hinting is appropriate (slight RGB hinting for most people), which is fixed by D12925: Parse global config files. Remove 'Vendor default' option. Fix changes not recognized.. But that's not really related to this. The idea of making the size bigger is to increase readability, which is just something that naturally comes from having the text be bigger; this is not controversial. The question is not whether larger text is more readable (it is), it's whether or not it's worth it because of the trade-offs involved.

I would probably do 13 pt titlebar and no bold

rkflx added a subscriber: rkflx.EditedAug 16 2018, 7:41 AM

@ngraham I've got a couple of questions regarding your RFC:

It's notable that all other desktop operating systems use at least 11pt as the size of their UI font, and some go much larger. The experiment has already been done for us and the results appear to have been positive judging by the fact that everyone else made the jump to 11pt UI font size. Perhaps we should too.

I tried to verify that, so I took some screenshots:

  1. As far as I can see, the most-used desktop operating system uses the smallest fonts. Why is it that my screenshots show a smaller or equal size when comparing "other desktops" to our current and well-balanced offer, but according to your comment they should show a much larger size? Do you have screenshots? Did you compare 100% scaling for each?
  1. As far as I know you are using a laptop where a fractional scaling factor slightly larger than 1 would be in order, but instead you compensate by increasing the font size. Nothing wrong with that, but I wonder how large the fonts will become on other people's displays, e.g. a standalone cheap 1080p monitor with a DPI below 100, which are very common. I fear this will make it better for some people and worse for others, creating nothing but churn. Did you test this with several of said displays?
  1. How does your suggestion relate to both the DPI value of your hardware and what Xorg uses? Do we actually set a higher DPI value for Hi(gher)DPI hardware automatically, so the actual size to the eye is independent of the display in use? If not, why not?
  1. This only scales fonts, but other UI elements are unaffected, so proportions as originally intended by the creators get distorted. Would it make sense to refer users to fractional scaling instead, or even make it automatic once it works well enough?
  1. Are there many bug reports of users complaining about too small fonts in Plasma? If so, could you add links?

[RFC] Increase default font sizes by 1 pt

Would it make sense to put the actual problem you want to solve (which I'm not yet sure about) in the title, and not present the solution immediately? We have many variables here (display hardware, viewing distance, Xorg fonts dpi, personal preferences), I don't see most of them accounted for yet.

Just to add another fact to the discussion:

The metric pt is an absolute measure for the size. In computing we use the desktop publishing point which is 1/72 inch (see https://en.wikipedia.org/wiki/Typographic_unit).
Therefore ideally 10 pt sized font should be rendered the same size independently from display resolution.

rikmills added a subscriber: rikmills.EditedAug 16 2018, 8:12 AM

Increasing the default font size was suggested for Kubuntu in T7864

I have the same concerns/objections as I did then.

As has been mentioned this scales other UI elements like kicker. Having also tested at the time with a fairly typical 1600x900 laptop display, it looked quite awful. Not every KDE user has a nice large res or hidpi display. In fact usage of FOSS OS often seems to be wider for lower end spec machines and displays.

If this change goes ahead, I may have to give serious thought to overriding new default in our Kubuntu settings package, but that brings issues of diverging from what will then be tried and tested defaults (I hope) which is additional testing burden on a small team.

I use an old laptop with 1280×800 display (not like you should really count for it, this is old).

Noto Sans 10, good readable (but ugly for Arabic):


Noto Sans 11, huge (and ugly for Arabic):

Mada Medium 10, good not that much readable and good for Arabic:

Mada Medium 11, huge and good for Arabic:

Mada Medium 10.5, perfect for me:

Conclusion

11pt is too much.

I fear this will make it better for some people and worse for others, creating nothing but churn. Did you test this with several of said displays?

I would agree with that to a large extent. The current defaults while not being ideal for everyone, are in my opinion at a reasonable middle ground already. Increasing even by this 1pt starts to skew this too far one way.

  1. Are there many bug reports of users complaining about too small fonts in Plasma? If so, could you add links?

I can't comment on bug reports, but as far as I can think with user feedback on Kubuntu, the default fon't size has not been an issue of concern on any serious level.

filipf added a subscriber: filipf.EditedAug 16 2018, 9:02 AM

Even in your screenshots 11pt looks too big and 13pt titlebars are just obscene.

There are a few use cases where it pays of to have 11pt fonts - namely when you have full HD laptop screens that would require 1.2 scaling and you'd prefer to do it the fonts way. On proper monitors it just looks too big. It' not necessary, but if you want to point out the titlebars an elegant touch can be to just have it the same size as the default font size, but use the semibold font style.

I'm also not sure if other OS' default to 11pt. In Windows 7 you could easily check these settings in the window metrics dialog and I'm pretty sure it was either 9 or 10 by default. On the other hand, I don't have too much experience with Windows 10. It seems to me that their new Fluent Design project is using larger fonts than before, but it also seems to me like they're inconsistent about font sizes right now .

As for font rendering, if you want to mimic the Apple's approach of preserving the typeface then the settings are: hinting=off, subpixel rendering=rbg, lcdfilder=lcddefault. Hinting distorts the typeface and is prone to producing jaggedness that, yes, goes away a bit when you increase font sizes.

filipf added a comment.EditedAug 16 2018, 9:18 AM

Have a look at maybe one of the worse scenarios where this change would reflect itself - a measly 19" 1280x1024 monitor (kind of obsolete sure, so this is more for illustrative purposes):

Kickoff now takes up a too large portion of the screen, the titlebar and its buttons have consequently grown in size as well and one of the desktop icon filenames is now broken up.

EDIT: An this is why using 13pt fonts for titlebars looks obscene. Nate didn't seem to restart KWin hence the size of the titlebar and buttons remain unchanged in his screenshots, however:

filipf added a comment.EditedAug 16 2018, 9:27 AM

As an alternative solution maybe you could consider changing the default font DPI from 96 to 102. This would be a much subtler change and yet the fonts are bit bigger and look nicer. EDIT: and it would be easier for users who don't like it to just turn it off, it's one checkbox.

Before:

After:

I don't know if it's a more controversial move from a technical point of view than changing fontsizes though. E.g. qt5ct offers 102 as a default value so perhaps not?

rooty added a subscriber: rooty.Aug 16 2018, 11:15 AM

nah, it's too disproportionate with regard to the sliders and bars in all the Qt apps that use the fonts, (it's just too big, pun intended)
10pt is the best, as well as 9pt for Hack

How does your suggestion relate to both the DPI value of your hardware and what Xorg uses? Do we actually set a higher DPI value for Hi(gher)DPI hardware automatically, so the actual size to the eye is independent of the display in use? If not, why not?

I have several HiDpi displays on a few machines and Not a single one has changed the dpi for me. I have had to set the dpi on each machine. After that is done pretty much all scaling issues go away. Other then the occasional icon or control w/ a hard coded size. I do not use scaling on my hidpi displays at all it is not needed after the dpi is correctly set.

Other Os sizes.

Looking around the net and trying on some windows machines here it seams they really bury the font size settings since i was not able to find them in the font or display area, they only provide an option to adjust scale of the screen or the dpi . To change the font setting you need to modify the theme your using. After digging around I checked on windows 7 the default for is 9pt. every thing with a font. I was not able to find that box on the windows 10 machine tried on.

After digging around I checked on windows 7 the default for is 9pt. every thing with a font. I was not able to find that box on the windows 10 machine tried on.

They removed that particular configuration box back in Windows 8. Anyway, this is Windows 10:

The default icon fontsize probably still defaults to a 9pt, while "small" is 8pt. Like I said, the newest bits of UI have larger fonts; maybe what's in the settings menu actually is 11pt. But either way Windows does not default to 11pt as a whole. We have a much consistent experience here however, with 10pt being the sanest option for the largest portion of devices.

This is exactly the sort of topic that will benefit from the telemetary data that we will hopefully start to have soon. Then we can back things up with facts.

Otherwise it can come across as "my personal preference is blah" - and whilst that's exactly how the original ones came about, making a change (especially mid major-cycle) faces more resistance.

filipf added a comment.EditedAug 17 2018, 3:19 PM

Except it doesn't really boil down to personal preference, unless we're taking eyesight into the equation.

11pt does not just make the fonts look somewhat big, but also increases UI elements, most notably the titlebar (and its buttons) and Kickoff. This is why 13pt titlebars is an even worse idea. This change would most adversely affect lower resolution monitors and I guarantee you'd have complains. Even on a decently sized 1080p monitor it looks too big. On the other hand, there was a good question asked here already: have we had any complaints from the community now regarding the 10pt default?

If we take the 'how it works in other OS' as a line of argumentation, the comparison is invalid; they don't default to 11pt and consequently everything in Plasma would look bigger than what people are used to. Windows is an inconsistent mess, but the most prominent font size is 9pt - what was previously known as icon font size. I have no experience with macOS, but there has been a screenshot here shown.

I've also taken a look at GNOME (Fedora 28). At first glance, Nate was right, there is a major competitor using 11pt as a default:

This is, however misleading. Cantarell and Noto Sans do not have the same metrics. 11pt Cantarell is in fact the equivalent of 10pt Noto Sans. In the following pics you can see that Noto Sans is substantially bigger at 11pt than Cantarell.

Finally, if GNOME were using Noto Sans, they'd be using it at 10pt as well because only then is it comparable to 11pt Cantarell:

And conversely, if we were using Cantarell as the default font we'd use it at 11pt. But defaulting Noto Sans to 11pt would be a mistake.

EDIT: My bad, this Lisu variant of Noto Sans they had in Fedora is a bit bigger than regular Noto Sans. Still, Cantarell has comparatively smaller metrics so it's 11pt is probably like 10.5 Noto Sans.

I feel that Windows' font rendering produces significantly sharper fonts than anything else. FWIW I think it's both their choice of font (Segoe UI) and their ClearType technology that makes text in Windows easy to read even at 9pt. Increasing Noto Sans' size doesn't make it sharper in my eyes; perhaps AA and general font rendering is worth looking at.

I feel that Windows' font rendering produces significantly sharper fonts than anything else. FWIW I think it's both their choice of font (Segoe UI) and their ClearType technology that makes text in Windows easy to read even at 9pt. Increasing Noto Sans' size doesn't make it sharper in my eyes; perhaps AA and general font rendering is worth looking at.

Possibly. But I bet what is more likely is that they set those values back when we didnt have FHD and touch screens and just stuck with it. That's Windows, they don't do as much revamping as much as they just add stuff on top of what already exists.

But font rendering in Windows is also a mess. ClearType is an old technology from a different time and has been deprecated in favor of Greyscale (which is, funny enough, worse than ClearType because it's fuzzier). It was seen as an enhacement when it was implemented moreso because what they had before was awful and because screens were bad rather it being a great way to render fonts. Nowadays there may even be a 3rd type of rendering in Windows IIRC; they all co-exist in the same environment. But what's common to all of them is that they crudely alter fonts to artificially fit a pixel grid. In practice this usually means they thin them out and distort their proportions, making them either taller/shorter or wider/narrower than intended. Fonts also look jagged thanks to this. More real life consequences of distorting the typeface is that it ruins the vision the (non-Microsoft) font creator had for its font, that what is on the screen does not match printed material, that websites and PDFs may not look as you envisioned them etc. This is partly one of the reasons why design people prefer Macs and once you develop an eye for what fonts actually look like, you may also tend to see hinting as making fonts uglier. For instance, you can have a look at how Phabricator's Lato font looks like on your phone (provided the screen resolution isn't too shoddy) and then compare it with what hinting does to the font on the computer screen. On your phone it looks like it's supposed to.

However, probably owing to most of Linux users being Windows users initially, from what I've seen the larger part of Linux community wants Freetype to be similar to Cleartype. This is not just unfortunate for the reasons mentioned above, but also because Freetype is already a great font renderer. I could provide plenty visual corroboration regarding this issue, but since this is not the topic here per se I just wanted to point out that there is a different approach than wanting "sharp" looking text. We could be going after fonts looking "crisp" instead, all the while remaining true to the typeface.

mart added a subscriber: mart.Aug 20 2018, 10:12 AM

I like the way this looks, I would like to push it further for clarity and ask for window title at 13 and bold. I feel people stand to benefit from seeing a window title that is readable, especially when we have a dark color background default.

that's a thing i would like to talk about more (also because for this i don't have research to point at, just a strong opinion on my side ;)):
I really hate bold fonts anywhere in the UI. it should be a thing for documents and documents only.
I would really like us to try to avoid bold anywhere, but at most use the size for things that should be more prominent than others

mart added a comment.Aug 20 2018, 10:15 AM

+1 for 11pt in general by the way

rooty added a comment.EditedAug 20 2018, 10:47 AM

there's simply no need to change this, Noto Sans at 10 pt is perfectly readable and blends in with the UI elements better
Noto Sans at 11 pt looks disproportionate, perhaps if a different font were used (like filipf said, Cantarell) it would look more presentable

@davidedmundson
why should telemetry be the reason the UI fonts be changed? neither Apple nor Microsoft does this?
what do you mean by facts though, isn't telemetry just a bunch of personal preferences heaped up?

what do you mean by facts though, isn't telemetry just a bunch of personal preferences heaped up?

Yes.
That is /considerably/ better than having just a few people's personal preferences heaped up, which is the current state of this thread.

what do you mean by facts though, isn't telemetry just a bunch of personal preferences heaped up?

Yes.
That is /considerably/ better than having just a few people's personal preferences heaped up, which is the current state of this thread.

will you be using your telemetry data to dictate whether the default's double click to open or single click to open?

will you be using your telemetry data to dictate whether the default's double click to open or single click to open?

It would certainly be a large factor, yes,

will you be using your telemetry data to dictate whether the default's double click to open or single click to open?

It would certainly be a large factor, yes,

that's not a yes 😆 but hey baby steps

@ngraham Could you comment on why (on your personal machine) you went for increasing the font size instead of changing the DPI value? (If this is a UI issue, telemetry might give skewed results, BTW.)

I think the font DPI setting needs to be much more hidden or even disappear completely IMHO.

But why? The DPI spinbox allows for much more fine-tuning, and also affects all other places where the fonts you are changing here are not even used. If a display has smaller physical pixels, this affects everything and not only the standard fonts, doesn't it? (And in some cases you might not want fractional scaling, and only change fonts DPI.)

what do you mean by facts though, isn't telemetry just a bunch of personal preferences heaped up?

Yes.
That is /considerably/ better than having just a few people's personal preferences heaped up, which is the current state of this thread.

Everyone unfortunately thinks numbers = hard facts and this can be pretty erroneous and lead to manipulation. If you are going to resort to telemetry for making decision such as this one (which you shouldn't, but potentially only to support claims):

  1. please make sure to know what kind of sample you are operating with ie. who has turned ON telemetry (since I see it's going to be opt-in) -> the expectation here is that you'll have developers overrepresentened because regular users tend to dislike even the mention of telemetry
  2. make sure to record the screen resolution used AND the screen size -> of course people with small high-res screens are going to be more likely to increase font sizes
  3. make sure to take into account that not all fonts have the same metrics-> I don't believe you are going to build a database that would somehow categorize fonts in relation to how big they are on their own. Ever turned on one of those niche fonts out of fun, only to have to increase them to 14pt because they're just so small? Cantarell is smaller than Noto Sans e.g. You must take these things into account.
  4. above all, please take into account that you will have zero data on what someone's eyesight is like, which is a major variable here

You are never going to get a full picture with numbers, not even if you solve the first 3 points suitably. Qualitative insights are much needed here, so it's good to have look if someone's been saying anything about fontsizes and also to ask e.g on Reddit to see what the users' input is.

Let's not forgot the method of experiment either, if still feeling about this strongly, as a more sensible change to test this I'd suggest increasing the font DPI to 102 and then try it out in KDE Neon for a little while. There are too many steps and arguments being skipped here.

rooty added a comment.EditedAug 20 2018, 12:57 PM

@ngraham Could you comment on why (on your personal machine) you went for increasing the font size instead of changing the DPI value? (If this is a UI issue, telemetry might give skewed results, BTW.)

I think the font DPI setting needs to be much more hidden or even disappear completely IMHO.

But why? The DPI spinbox allows for much more fine-tuning, and also affects all other places where the fonts you are changing here are not even used. If a display has smaller physical pixels, this affects everything and not only the standard fonts, doesn't it? (And in some cases you might not want fractional scaling, and only change fonts DPI.)

i think the DPI thing is a mistake too, removing the font DPI setting goes against the grain of what a lot of people (including yours truly) use KDE for, customizability

@ngraham if you want to set a different default value fine, but please don't remove the option i.e. emulate Apple's mistakes by locking things down... macs work in spite of their flaws, not because of them; you can always put in a wizard that runs on booting for the first time and asks people for their preferences... i still wouldn't hardcode them (what if you change your mind later on)

rooty added a comment.Aug 20 2018, 1:16 PM

P.S. wasn't this problem settled already in T7864?

P.S. wasn't this problem settled already in T7864?

No, that's a task on Kubuntu workboard about changing our distro specific defaults.

rooty added a comment.Aug 20 2018, 1:30 PM

P.S. wasn't this problem settled already in T7864?

No, that's a task on Kubuntu workboard about changing our distro specific defaults.

ah sorry my bad

filipf added a comment.EditedAug 20 2018, 2:18 PM

! In D14869#311980, @rooty wrote:
you can always put in a wizard that runs on booting for the first time and asks people for their preferences... i still wouldn't hardcode them (what if you change your mind later on)

I think this is a good idea. We still get some newcomers complaining that the configuration options are too much for them so we could make a simplified wizard that would address the essentials. This would also perhaps tone down the need for and discussion about flipping defaults. We could have questions such as:

  • how would you like your desktop to be organized? Windows style, Mac style, Ubuntu style etc.
  • do you prefer a light or dark theme? -> with allowing an option for a light theme with a dark panel
  • how big should the fonts be? -> just a slider with real-time preview, if not of Plasma then sample text in the dialog
  • do you wish to use single click or double click to open files?
  • etc. -> something else of relevance

It wouldn't even necessarily have to pop-out upon first boot, just be somewhere prominent in system settings. But even if it pops-out, that's not that unprecedented in the Linux world, XFCE for example asks you for the preferred panel configuration. And you can always add a big SKIP button.

! In D14869#311980, @rooty wrote:
you can always put in a wizard that runs on booting for the first time and asks people for their preferences... i still wouldn't hardcode them (what if you change your mind later on)

I think this is a good idea. We still get some newcomers complaining that the configuration options are too much for them so we could make a simplified wizard that would address the essentials. This would also perhaps tone down the need for and discussion about flipping defaults. We could have questions such as:

  • how would you like your desktop to be organized? Windows style, Mac style, Ubuntu style etc.
  • do you prefer a light or dark theme? -> with allowing an option for a light theme with a dark panel
  • how big should the fonts be? -> just a slider with real-time preview, if not of Plasma then sample text in the dialog
  • do you wish to use single click or double click to open files?
  • etc. -> something else of relevance

    It wouldn't even necessarily have to pop-out upon first boot, just be somewhere prominent in system settings. But even if it pops-out, that's not that unprecedented in the Linux world, XFCE for example asks you for the preferred panel configuration. And you can always add a big SKIP button.

I am all for a new user wizard. I have stated this on several of these kinds of threads.

ngraham added a comment.EditedAug 20 2018, 5:21 PM

Apparently people are passionate about font sizes. :)

after reading everyone's comments here, it seems like this will probably not work on its own, but has usefully exposed a number of other changes that we should make before revisiting it (if we ever do):

First of all, it seems confusing and unnecessary to have so many methods of adjusting the user interface's scale:

  • Force Fonts DPI in the Fonts KCM. I've been told before that this is an ugly hack that people shouldn't use, but maybe that's not true?
  • Adjusting the font size in the Fonts KCM automatically adjusts the size of user interface elements in a similar manner to the Force Fonts DPI setting.
  • User interface scaling in the KScreen KCM. This appears to be the recommended method, though it's still quite buggy and exposes a lot of visual artifacts (which are steadily being fixed, to be fair). Also, it currently only supports integer scale factors in Wayland.
  • Resolution slider/combobox in the KScreen KCM. This is probably not something users should use for scaling the UI (do people change their screen resolutions very often anymore?), but it's there anyway.

We should probably figure out some way to make it clearer what is the one officially sanctioned method of scaling the user interface to match your display's pixel density.

Second, it seems like we should do some scaling automatically so that people don't see radically different sizes for their user interface depending on the pixel density of their screen. If you measured window titlebars with a caliper on multiple screens of different DPI values, the height should always be the same. This should also be automatic out of the box if possible, so that people don't need to manually configure it to get it to work. I think users would really love this feature, which would in practice probably depend on sorting out the first issue first.

Third, maybe it makes sense to increase the titlebar font by a bit in order to emphasize it, but 13pt bold is super excessive.

Does this sound sensible to everyone who's chimed in here?

Apparently people are passionate about font sizes. :)

after reading everyone's comments here, it seems like this will probably not work on its own, but has usefully exposed a number of other changes that we should make before revisiting it (if we ever do):

First of all, it seems confusing and unnecessary to have multiple methods of adjusting the scale of the user interface:

  • Force Fonts DPI in the Fonts KCM. I've been told before that this is an ugly hack that people shouldn't use, but maybe that's not true?
  • Adjusting the font size in the Fonts KCM automatically adjusts the size of user interface elements in a similar manner to the Force Fonts DPI setting.
  • User interface scaling in the KScreen KCM. This appears to be the recommended method, though it's still quite buggy and exposes a lot of visual artifacts, which are steadily being fixed, to be fair. Also, it currently only supports integer scale factors in Wayland.
  • Resolution slider/combobox in the KScreen KCM. This is probably not something users should use for scaling the UI (do people change their screen resolutions very often anymore), but it's there anyway.

Second, it seems like we should do some scaling automatically so that people don't see radically different sizes for their user interface depending on the DPI of their screen. If you measured window titlebars with a caliper on multiple screens of different DPI values, the height should always be the same. This should also be automatic out of the box if possible, so that people don't need to manually configure it to get it to work. I think users would really love this feature, which would in practice probably depend on sorting out the first issue first.

Third, maybe it makes sense to increase the titlebar font by a bit in order to emphasize it, but 13pt bold is super excessive.

Does this sound sensible to everyone who's chimed in here?

This sounds good to me!

... do people change their screen resolutions very often anymore?....

Yes I have to change my resolution quite often and its almost always because of one of two things.

  1. Some application that was in fullscreen at a specific resolution has crashed (often a game via wine). This maybe solved by using wayland?
  2. I've added a new screen and its not set to the correct resolution ( A second / third screen). This is alot less of an issue then the first one.

^ Same here. It's certainly not unnecessary when a Wine game throws you back into a 640x480 Plasma, in fact it's crucial; you have to check with other users before calling it that! I think it's also sometimes used to align or tweak the screen resolution with the projector? The options the way they are are fine in my opinion, especially since display scaling via KScreen is bugged right now. When it gets fixed just somehow note it's the recommended method of scaling the display, no need to remove the other options.

But back to the point, having automatic scaling would be great, yep.

rooty added a comment.Aug 20 2018, 7:57 PM

Third, maybe it makes sense to increase the titlebar font by a bit in order to emphasize it, but 13pt bold is super excessive.

Does this sound sensible to everyone who's chimed in here?

Yes, sounds good, aside from:
(1) The emphasis you're describing might be more suitable for inactive titlebars (because it's hard to tell what the window title of an inactive window is, seeing as the title is gray and the titlebar is sort of white) rather than active ones (that are already black-ish with white text on them). And in this particular case, a change of color may be all that's needed.
(2) We need the resolution box in the Display and Monitor section, it's too much of a leap to expect to never change your screen resolution again - the combo box is a nice fallback.

No, I would never propose removing the resolution slider/combobox. It's an implementation detail, but still an important one. What I am proposing is that we could somehow unify the various screen UI scaling methods and present them in a clearer and more prominent manner.

No, I would never propose removing the resolution slider/combobox. It's an implementation detail, but still an important one. What I am proposing is that we could somehow unify the various screen UI scaling methods and present them in a clearer and more prominent manner.

now that's a great idea.
might not also be a bad idea to add a preview/screenshot thingy right next to the settings so people can see what the settings look like without having to apply them?

ngraham abandoned this revision.Aug 24 2018, 8:25 PM

Let's continue the first part of the discussion in T9500: Unify UI scaling methods.