Skip to content

applets/digital-clock: make time/date spacing look like typographic space

Reason for the change

Because the time/date have the same text style, to the user the date and time appear to be the same text, so it's surprising to have the distance between them be a spacing that's more suitable for two separate applets.

The timezone has a different style, so this MR keeps the spacing between the timezone and the time as smallSpacing.

This MR takes the approach of just measuring the width of a space then applying that as the spacing, to minimize changes.

I'm keeping this draft for now as I still want to fix the extra spacing on the right which this change makes worse.

Test plan

I placed several digital clock widgets on the desktop to see various configurations at the same time, comparing the before and after. The results are shown in the screenshots; the configurations tested are:

  • Iosevka 16pt, show date next to time, with date format being "14 June", which produces the same result as "dd MMMM" except (a) I don't have to switch my system to English and (b) that I wrote the wrong month, but the example still stands
  • Jost* 16pt, show date next to time, using the short date format ("2024/07/14") (sans-serif case)
  • Iosevka 16pt, show date next to time, using the short date format ("2024/07/14") (narrow monospace case)
  • Source Code Pro 16pt, show date next to time, using the short date format ("2024/07/14") (wide monospace case)
  • Jost* 16pt, show date below time, as a desktop widget (making sure the change does not have an effect outside of oneLineMode)
  • Iosevka 16pt, show date below time, as a desktop widget (making sure the change does not have an effect outside of oneLineMode)

Screenshots or screen recordings

Target situation (monospace, date format has space)

Before After
monospace-spacedate-before monospace-spacedate-after

The two visual spaces (one is a space character, the other is the Grid spacing; the user shouldn't have to know) are noticeably different before. After this change, this inconsistency is resolved.

Other situations

Before After
monospace-nospace-before monospace-nospace-after
sansserif-nospace-before sansserif-nospace-after
widemono-spacedate-before widemono-spacedate-after

When there is only one line, the difference only becomes noticeable for wider mono fonts. This should still fit better to the expectations of a monospace font, however.

The extra space at the end is something that should be fixed (the one line applets are all at their minimum width). It was also present before, but an extra smallSpacing at the end was just less noticeable. Edit: after more testing I am no longer sure about how to tackle this extra margin. It is only there when timezone is not displayed. It seems to be related to how in one line mode the width of the content item is set to the width of the date + the right margin of the date + the width of the grid; but removing the margin from this calculation causes the item to poke outside of the left edge. Currently, the grid is anchored to the right edge of the content item, then the date is anchored to the left of the grid; flipping this so that the date is anchored to the content item from the left, then anchoring the grid to the right of the date seems to get rid of this margin in some cases, but the extra margin remains in other cases. TL;DR I think this is very hard to fix without major rewrites to the applet, and I now want to put it outside of the scope of this MR.

Before After
monospace-twoline-before monospace-twoline-after
sansserif-twoline-before sansserif-twoline-after

There is no difference when there are two lines, as this change only touches the column spacing (and due to the way things are hooked up, the date's right margin value; unused when it's centered).

Bugs fixed

BUG: 490252

Edited by Kisaragi Hiu

Merge request reports