Fonts KCM simple vs advanced modes
OpenPublic

Mock History

Current Revision41

Mock Description

Idea for the simple/advanced mode split for the Fonts KCM.

ngraham created Fonts KCM simple vs advanced modes.Jul 31 2018, 10:01 PM
ngraham added a project: Plasma: KCM Redesign.
ngraham added subscribers: abetts, harmathy.

This appears to be missing the "Force DPI" option that is in our current KCM.

I very like this idea! However in “simple” I would like to add selectable previews for different rendering options:

Anti-AliasingHinting
offnone
offfull
grey scalenone
grey scaleslight
grey scalemedium
grey scalefull
subpixelnone
subpixelslight
subpixelmedium
subpixelfull

The sub-pixel rendering settings seem very much advanced material to me. If you want that stuff, it's all available there on the Advanced tab, and per the mockup above, there's still a nice big preview area on top.

Sub-pixel rendering is default for desktop systems. But there are people who don't like sub-pixel rendering for its colour haze.

mart added a subscriber: mart.Aug 20 2018, 9:43 AM

so simple/advanced modes tabs, ever. please.
in fact, i don't want to see a single tabbar in any of the new kcms.

this is the usual "every person uses 10% of the feature, but it's a different 10%" moreover, the "simple mode" risks to be useless for everybody: not being able to change size there for instance is a no go.
and rather than a discussion on what should be on that thab and what not, it shows more that the concept is flawed.
there are more graceful ways for semi-hiding less widely used controls, that don't make you switch to a completely different ui to do the same thing.

In general: in UI "modes" are bad, sometimes they can't be avoided and there are strategies to make them suck less, but inserting them gratuitously where not needed, is a no go.
further reading on modes and why they should be avoided.
http://en.wikipedia.org/wiki/Mode_(computer_interface)
http://www.usabilityfirst.com/glossary/mode-error/
https://www.embedded.com/electronics-blogs/murphy-s-law/4025544/Modes-and-the-user-interface
https://ilyabirman.net/meanwhile/all/timed-modes/
https://baymard.com/blog/accordion-and-tab-design
https://blog.martindoms.com/2011/01/24/poor-ui-design-can-kill

Inline Comments

Instead of the tabbar i would like to see just some of those fields hide-able with a checkbox or something and the part under antialiasing as well

we moved away fom "detached" previews everywhere else (wallpapers, cursors, icons, etc
the preview should be in the "noto sans" box

preview should go inline here

I would veto an any tabbar on any final design of kcms

this can't be just a combobox but the full picker is needed, or you can't pick size, weight etc (and this *is* very basic stuff)

I appended my first try of a mockup. There is no preview rendering of the different rendering options yet. I would have to add another image provider for that or generalize the existing previewimageprovider.

we moved away fom "detached" previews everywhere else (wallpapers, cursors, icons, etc the preview should be in the "noto sans" box

That would mean implementing a solution closer to M120.

rjvbb added a subscriber: rjvbb.Fri, Nov 23, 9:17 AM

Found this by accident, and had only one immediate thought

why?

And I see mart already objected with much the same thoughts I have.

There is already an "Adjust All Fonts" button in the current UI, of which I'll presume it tries to do something intelligent with the fixed font. So the only thing missing at a quick glance is a quick control to change all font sizes in concert. That shouldn't be hard to add.

This is not only about choosing a Font, but also about selecting suitable rendering options.

Users coming from Windows are used to heavily hinted font rendering and usually dislike the colour haze of subpixel rendering, whereas Mac users are used to smooth subpixel-anti-aliased font rendering. However most of them have no idea about font rendering techniques, like hinting, anti-aliasing or subpixel rendering. But most of them have a strong opinion on how text should be rendered. Thus having them select pleasant rendering option in a visual way seems very natural to me.

rjvbb added a comment.EditedFri, Nov 23, 10:13 AM

The current KCM already has a control for that.

However:

  • On Mac you don't have control over the font rendering used: without jumping through hoops Qt will use CoreText and so fonts will look exactly as they look in other applications. Even if you do manage to activate the Freetype font renderer you still don't get anti-aliasing options.
  • AFAIK the same applies to MS Windows
  • control over the kind of rendering is done outside of Qt even under X11 and probably Wayland too (unless you use a Qt-based compositor?).

and last but not least

  • the KCMs are not officially available outside of the Plasma sphere (= not on Mac nor MS Windows) and for the most part they are provided by a project that for the rest indeed doesn't make sense elsewhere.

EDIT: I don't agree with how jealously Plasma keep these to themselves, some KCMs certainly make sense across all platforms and I maintain Mac packaging for them. But you just don't get to justify changes because of Mac or MS Windows and at the same time claim the software in question is out of limits there ;)

I'm not saying that the current KCM couldn't benefit from a layout redesign, say with a collapsable advanced settings "drawer" (cf. the cmake settings in KDevelop's project configuration dialog).

Sorry for creating confusion! This is also not about kcm fonts on other platforms.

  • As you pointed out, changing font rendering behaviour on those platforms is limited (AFAIK on Mac there simply no hinting implemented).
  • kcm fonts is fontconfig specific. (It's even non-tirival to translate rendering options from fontconfig terminology to freetype, which is in fact separately implemented in libXft, Qt and pango)

The idea came from a tool, which was created at the city administration of Munich, during the migration of desktop systems from Windows to Linux to increase users acceptance. Users, who were used to the heavily hinted rendering of windows complained about the default rendering (anti-aliasing and only slight hinting) to be blurry. But instead of enforcing heavy hinting by making that the default, we gave them a tool to select a suitable configuration visually. Side Note: At that time hinting with freetype wasn't state of the art due to patent issues, but that has changed with the v40 engine in freetype 2.7.

At that time hinting with freetype wasn't state of the art due to patent issues, but that has changed with the v40 engine in freetype 2.7.

Don't forget the Infinality patches to Freetype and FontConfig. With those you get a font rendering quality that is better than that on Mac (and probably MS Windows too) IMHO. Across the board, not just in KDE/Qt applications.

rjvbb added a comment.Mon, Dec 10, 6:22 PM

Why not make these separate KCMs? I don't know how usual it is to open just the fonts KCM (kcmshell5 fonts) or if the vast majority of users gets to that config page only via the systemsettings app. For those you don't need to implement a tab-like mode switch because systemsettings already provides that for different KCMs. And users who go through kcmshell5 can probably learn quite easily to modify their commandline.
This approach also means you don't have to worry about whether and how to implement mode persistence.

That said, there's nothing easy about the easy mode, currently. It reminds me of MS's ClearText rendering configuration wizard, but that uses multiple screens and I think even has a before/after summary screen at the end. Even then it's pretty hard to judge how the font colour (technical term, not actual RGB values) will come across in larger bodies of text and in UI controls of different colours.

harmathy updated an image's (LiMux Expert Mode.png) description. (Show Details)

Why not make these separate KCMs?

In principle KCM fonts does two things:

  • set fonts
  • set rendering options

Both "modes" cover the same two purposes. If at all, I would separate those into two KCM modules.

But then the appearance of fonts, especially on low resolution displays, depends on the rendering options. The user would have to switch between two modules, until a suitable font and rendering settings combination is found.

EDIT: I don't agree with how jealously Plasma keep these to themselves, some KCMs certainly make sense across all platforms and I maintain Mac packaging for them. But you just don't get to justify changes because of Mac or MS Windows and at the same time claim the software in question is out of limits there ;)

kcm fonts is fontconfig specific. (It's even non-tirival to translate rendering options from fontconfig terminology to freetype, which is in fact separately implemented in libXft, Qt and pango)

I figured, that until the re-implementation of the UI in QML the kcm fonts module was in fact platform independent. The fontconfig specific parts would just be excluded via pre-processor.

rjvbb added a comment.Mon, Dec 10, 7:31 PM

It's not clear who wrote that about being fontconfig specific (or the IMHO incorrect suggestion that Freetype is implemented 3x).

The font rendering bit of the KCM is undoubtedly backend-specific (and indeed doesn't appear when run on Mac, even if you build Qt with Freetype and FontConfig support).
The font selection bit is cross-platform (and that is what gives the KCM its name).

Separate KCMs for font and for rendering selection would indeed make sense, and the one for rendering could offer the choice between opening advanced settings or a wizard (or the "wizard button" could just occupy a proeminent position on the panel so you no extra clicks are needed to access it).

It's not clear who wrote that about being fontconfig specific (or the IMHO incorrect suggestion that Freetype is implemented 3x).

I wrote that, just a few days ago. The current master is fontconfig only, since there is no way to leave the fontconfig specific parts out of QML.

It's not Freetype, which is implemented three times, but the translation of fontconfig settings into Freetype render flags:

rjvbb added a comment.Mon, Dec 10, 8:49 PM

The current master is fontconfig only, since there is no way to leave the fontconfig specific parts out of QML.

Nothing to do with KCM redesign (although...?!), but:
So it's not because of your style choice that the dialog look so ugly to me, but because they're written in QML instead of good ole QWidgets? That doesn't bode well for KDE's future (on my desktops) ...