Bug 473299

Summary: Lenght not fixed, other widgets move around when the time displayed changes
Product: [Unmaintained] kdeplasma-addons Reporter: svlmrc
Component: fuzzy-clockAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED INTENTIONAL    
Severity: minor CC: nate
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description svlmrc 2023-08-11 22:53:01 UTC 
The space assigned to the fuzzy clock is not fixed and varies with the lenght of the string displayed.
As a result, the other widgets move around when the time displayed changes.

So I guess it would be nice to change the default to have it assigned the max space possible (longest string to be displayed, also listening to language change events) or to have an option to set it that way manually.
Comment 1 Nate Graham 2023-08-12 13:30:57 UTC 
Is the widget on a panel, or on the desktop?
Comment 2 svlmrc 2023-08-12 13:45:01 UTC 
That's on a panel, specifically in a bottom-bar panel with task switcher, tray icons etc, between the tray icons and the "show desktop" button
Comment 3 Nate Graham 2023-08-12 19:54:54 UTC 
In that case unfortunately we don't have any great solutions. Here are the downsides to each one:

1. Fixed text size, variable size container (status quo): adjacent widgets jump around multiple times per day
2. Fixed text size, Fixed width container according to longest possible string: huge amount of wasted space most of the time
3. Variable text size, fixed width container according to some sizing metric: text size changes multiple times per day

I think we'd definitely get bug reports about option 2 or 3.

Do you have any ideas?
Comment 4 svlmrc 2023-08-13 00:08:14 UTC 
Another option could be setting the container size (via setting) in "maximum displayed characters" and move the text not fitting the viewport.
Like, elide the hour (less significative) and only show "...and 20 minutes" or whatever, optionally reverting to the normal HH:MM clock.
Or elide the text full stop, making it move on hover.

Dunno if it's better, the others are a bit hacky or bad IMHO
Comment 5 Nate Graham 2023-08-14 20:29:49 UTC 
Hmm, if we make it configurable, we just push the problem onto the user rather than solving it, so I don't think that's an option. If we revert to a normal clock, then the applet is losing its reason to exist. We can't elide the less significant part of the text since this would change for every language and so it can't be programmatically predicted.

Since it seems like there are no good options here, I think unfortunately we will have to stick with what we currently have.