Stop constant movement of notifications due to changing timestamps

Oneric commented

2023-10-18 23:29:04 +00:00

Member

When the notification timestamps change, so does the size the timestamp takes up and this may induce new line-wrapping for other text and thus change the size of a notification box. As a result theres constant movement and shifting around in the notification tray even when no new notifications occur.

This really bugged me and especially before I figured out where the movement came from also confuses me when I notice a movement, but then see no obvious change when focusing on the notification tray.

This change avoids the problem by setting a proper min-width for all types of notification timestamps.
I applied a variant of this (with 9em) for over a month via user styles and didn't run into issues.
For the proper patch I now also checked non-English localisations and tweaked it again.
Full details in the commit message.

When the notification timestamps change, so does the size the timestamp takes up and this may induce new line-wrapping for other text and thus change the size of a notification box. As a result theres constant movement and shifting around in the notification tray even when no new notifications occur. This really bugged me and especially before I figured out where the movement came from also confuses me when I notice a movement, but then see no obvious change when focusing on the notification tray. This change avoids the problem by setting a proper `min-width` for all types of notification timestamps. I applied a variant of this (with `9em`) for over a month via user styles and didn't run into issues. For the proper patch I now also checked non-English localisations and tweaked it again. Full details in the commit message.

Oneric changed title from ~~Stop constant movement of notifications due to changing timestamps~~ to WIP: Stop constant movement of notifications due to changing timestamps

2023-10-19 09:11:05 +00:00

Oneric commented

2023-10-19 09:23:22 +00:00

Author

Member

For the proper patch I now also checked non-English localisations and tweaked it again.

While I checked the short unit identifiers, I ofc forgot to check the translations for ago. Indeed many localisations use a string >4 characters with the longest being Indonesian with yang lalu which already takes up 10 characters before any actual time info is added (and Vietnamese also has a longer text with trước).
This would push the new worst case to 18em iimn, but I believe this is too long as it takes up more than half of the notification tray’s width.

Do we actually need the ago in the notification tray? With strings as long as yang lalu this might already be problematic apart from the movement, notifications can logically only ever be from the past and follow notifications already drop this part.

I’ll probably update the patch to drop the ago in notification timestamps. At first thought the only other alternative to an indiscriminate 18em that comes to mind would be to make the min-width locale dependent but I don't like this as it leaves the problem of the timstamp taking up too much space for some locales.
If anyone has other ideas I’d love to hear them and I’m also available on IRC (#akkoma-dev) for discussions.

> For the proper patch I now also checked non-English localisations and tweaked it again. While I checked the short unit identifiers, I ofc forgot to check the translations for ` ago`. Indeed many localisations use a string >4 characters with the longest being Indonesian with ` yang lalu` which already takes up 10 characters before any actual time info is added *(and Vietnamese also has a longer text with ` trước`)*. This would push the new worst case to `18em` iimn, but I believe this is too long as it takes up more than half of the notification tray’s width. Do we actually need the ` ago` in the notification tray? With strings as long as ` yang lalu` this might already be problematic apart from the movement, notifications can logically only ever be from the past and follow notifications already drop this part. I’ll probably update the patch to drop the ` ago` in notification timestamps. At first thought the only other alternative to an indiscriminate `18em` that comes to mind would be to make the `min-width` locale dependent but I don't like this as it leaves the problem of the timstamp taking up too much space for some locales. If anyone has other ideas I’d love to hear them and I’m also available on IRC (`#akkoma-dev`) for discussions.

Oneric force-pushed notification-writhing from 2065973058 to beee99e733

2023-10-24 22:56:18 +00:00

Compare

Oneric changed title from ~~WIP: Stop constant movement of notifications due to changing timestamps~~ to Stop constant movement of notifications due to changing timestamps

2023-10-24 23:00:02 +00:00

Oneric commented

2023-10-24 23:08:59 +00:00

Author

Member

Adjustments done, should be ready for review for real this time.

The new patches + limit are good for up to 3 weeks in all — except for two incomplete ones without proper short unit identifiers — localisations (more details in commit message). I believe this is reasonable enough and prevents frequent movements while not taking away too much space from usernames.

If we wanted to also reserve enough space for timestamps counted in months in all languages (e.g. Polish mies.), we’d need to bump min-width to 8em, which automatically will also be enough for up to 999 years in all sufficiently translated localisations.

Note: I don't know why Forgejo keeps showing only the old, single commit on the discussion view. In the “Commits” tab the two up-to date commits are displayed properly. (see beee99e733)

Adjustments done, should be ready for review for real this time. The new patches + limit are good for up to 3 weeks in all — *except for two incomplete ones without proper short unit identifiers* — localisations (more details in commit message). I believe this is reasonable enough and prevents frequent movements while not taking away too much space from usernames. If we wanted to also reserve enough space for timestamps counted in months in all languages (e.g. Polish ` mies.`), we’d need to bump `min-width` to `8em`, which automatically will also be enough for up to 999 years in all sufficiently translated localisations. **Note:** I don't know why Forgejo keeps showing only the old, single commit on the discussion view. In the “Commits” tab the two up-to date commits are displayed properly. (see beee99e733a6508e3744140ee73e8b7be8194d85)

floatingghost commented

2023-12-15 11:57:38 +00:00

Owner

WAIT you fixed this???

my actual saviour this has been annoying me for months and i never got around to figuring why it happend

praise

also very cool branch name

tried with a bunch of values and it seems good

thanks a lot!

WAIT you fixed this??? my actual saviour this has been annoying me for months and i never got around to figuring why it happend praise also very cool branch name tried with a bunch of values and it seems good thanks a lot!

floatingghost merged commit a8f193d4bd into develop

2023-12-15 11:57:47 +00:00

floatingghost deleted branch notification-writhing

2023-12-15 11:57:47 +00:00

floatingghost referenced this issue from a commit

2023-12-15 11:57:49 +00:00

Merge pull request 'Stop constant movement of notifications due to changing timestamps' (#353) from Oneric/akkoma-fe:notification-writhing into develop

Oneric referenced this pull request

2024-02-22 19:34:59 +00:00

RFC: dealing with timestamp-induced judder on TL #374

rat referenced this issue from a commit

2024-02-25 20:33:31 +00:00

Merge pull request 'Stop constant movement of notifications due to changing timestamps' (#353) from Oneric/akkoma-fe:notification-writhing into develop

Stop constant movement of notifications due to changing timestamps #353