30 July 2020 meeting

[Nate Graham]

Hello folks,

Here are the notes from our monthly meeting today:



Last month's meeting notes: https://share.kde.org/s/BkW6XoF6Dz8wtDf


# Colors and color schemes #

Should we continue to use QPalette?
- Yes and we should make broader use of it, and work with Qt people to 
get new roles in QPalette as needed. See 
https://codereview.qt-project.org/c/qt/qtbase/+/308109

Phase out all special stuff that kcolorscheme does: mostly using 
kcolorscheme api manually

Convert colorschemes to something that more closely matches color roles 
hopefully have the config file complatible-ish

KColorscheme still kinda needed for  the "color sets" (View, Header, 
Complementary etc)



# Icons #

For KF6, we will use 24px icons instead of 22px icons

FDO icon specification. Icon naming is pure convention. When we make a 
new iton, we follow the convention, but do not work with FDO to 
standardize the name itself.

KDE people have approval power to approve into the Free Desktop Spec
Proposal:
- Check for overlap in icon naming with other projects to get candidates 
for standardization
- Work with FDO to get our custom icon names added to the spec rather 
than doing it alone only within KDE
- Add HIG section to explain icon naming scheme with free desktop foundation



# Sound #

We want to use the FDO spec for sound

Our sounds are not currently compliant

Convert sounds to spec to FDO naming

Design new sound theme (In progress)



# Gestures/Hardware with touch capabilities #

Much discussion about whether convertible/hybrid devices actually make sense

Conclusion is that sometimes they can but regardless, we need to support 
them because people own them

We need to build touch friendliness into the basic UI rather than 
switching to an explicit touch-friendly mode like PlaMo



# Accessibility #

We all agree it's important

Not much time to actually do it

WCAG for web (there is also for desktop)

https://www.w3.org/TR/WCAG20/

https://www.w3.org/TR/wcag2ict/

Arjen will ask previous company about accessible software

Take low hanging fruit: Carl working on a contrast checker

Check if high contrast theme is compliant

Check if icons have their accessible.name property set



# How should we handle theming in KF6 #

Three options:
1. Preserve split between SVG-based Plasma themes and QTWidgets-based 
QStyles for desktop apps, and have Plasma use QtQuickControls2 directly, 
but apply the Plasma style to the controls rather than the desktop style
2. Standardize on Plasma themes for everything, and turn Breeze into a 
theming engine that takes Plasma themes and applies them to desktop apps
3.Like 2, but re-do plasma themes to use CSS or some other system less 
painful than SVGs


Discussion tended to favor option 2. Benefits include:
- Unified styling between Plasma and desktop apps becomes possible
- SVG-based application styles are easier to create than C++-based QStyles
- Can use the GHNS system to distribute and get application styles
- Could end up obviating the desire for Kvantum

Overall it seems possible but we need to address various technical hurdles:
- Ensure adequate performance; don't want apps to get slower compared to 
using QStyle-based theming
- Improve tooling and documentation for working with SVGs
- What to do in the case where a Plasma theme doesn't have an SVG needed 
to theme some UI element? Fall back to a widget style? Which one? How?





# HIG #

Marco to move qmlgrabber app into somewhere public. Done: 
https://invent.kde.org/mart/qmlgrabber

Writing style: move towards less wordy descriptive style and towards 
short recommendations for the use of standard components with lots of 
pictures and code examples

Make more mention of the *reasons* behind why we do things, without 
being too wordy

Proposed tighter integration between the HIG and the rest of the 
developer documentation, e.g. http://kde.carlschwan.eu/design/



# Documentation: Sphinx vs Mediawiki #

Balance of quality vs barriers to contribution

GitLab makes it easy to preview .rst changes; go to "View File" in the 
diffs tab. For example 
https://invent.kde.org/documentation/hig-kde-org/-/blob/c559a5b21a71a3ecac3e84e56cd5088c2836b00b/HIG/source/patterns/navigation/list.rst

Community wiki navigation is currently sort of random-seeming

Proposed new central documentation portal: 
https://phabricator.kde.org/T11096 and 
https://invent.kde.org/carlschwan/developer-kde-org and 
http://kde.carlschwan.eu/docs/

Translation is technically possible but not sure we want to do it 
because technical contributors need to know English anyway



# New Breeze theme/evolution #

Come to consensus regarding https://phabricator.kde.org/T13451. Conclusions:
- Overall we want to use the latest Blue Ocean as a base. We want a 
tiny bit more skeumorphism, but only a tiny bit. Current Blue Ocean 
seems generally good for this.
- We like the use of subtle contrast lines in UI elements to separate a 
component's background from what's beneath it (e.g. in Sliders, around 
menus window edges, etc).
- With respect to colors, we would like to try to use the current Plasma 
Blue highlight color as the base accent color rather than choosing a new 
one.
- We want to make default buttons in Blue Ocean to look more distinctive 
by using the accent color for its background and maybe outline too.
- Accordingly, we would like Blue Ocean to change the look of pressed 
buttons to not use the accent color for the background, and generally 
look a bit more like in Fusional/Skeumorpho
- We want to use an accent color outline + mild glow as a focus effect 
for controls in the view (buttons, checkboxes, switches, text fields 
etc), as shown in Fusional and parts of Blue Ocean already
- List item highlight effects should be different from menu item 
highlight effects; the latest Blue Ocean shows a good style.
- We want to see mockups for list views like Dolphin's details view.
- We'd like all UI elements to have the same frame height of 32px tall. 
For controls with a visible frame like pushbuttons and text fields, that 
frame would be 32px high. For controls with an invisible frame/click 
area like checkboxes, radio buttons, and switches, the invisible 
frame/click area would be 32px tall. The idea is that each row would 
have a consistent height for the frames (visible or invisible) of all 
controls in the row.

New Tools area MR: https://invent.kde.org/plasma/breeze/-/merge_requests/11
- Marco will take a look



# Current VDG pain points #

When a developer asks for a mockup, they generally receive a beautiful 
high-fidelity mockup in the new style that is not reflective of the 
current style and may be distracting
- Use low-fi (e.g. wireframe) mockups when the developer mostly wants to 
show layout and organization