Andrew can you comment please; screenshot matches your mockup: http://wstaw.org/m/2014/04/03/shutdown_mockup2_1.png

The intent in the design was to visually associate it with the progress bar (which has 2 primary visual reference points - the left edge and the right edge).  The other reason was to provide a steady anchor for the changing text. In retrospect, I think the mockup showing the target design would have been better if the right edge of that text lined up better with the right edge of the progress bar. (I also failed to notice in the implementation review that the "in xx seconds" should start with a lower case "I", but that's a separate issue).

In any event those was the main reasons for the design choice. Also center-alignment of visual elements with varying widths tends to create a "ragged-edge" one either side. Honestly though, for this particular issue, I wouldn't have massive heartburn if it were centered. Though, I think the better fix would be to line up the right edge of the text with the right edge of the progress bar  so it's right alignment looked less arbitrary.  That was my fault since the mockup showed much the same thing.

Hope this helps.

It is aligned with the right of the progress bar...
BUT the progress bar has a hidden right margin to try and hide an issue with slider handles.

I'll see how easy it is to fix that.

Hmm, that's right. If you remove that margin I'm guessing that when the progress bar and the slider share a layout, the edge of the slider groove and the edge of the progress bar won't line up...
Maybe whatever margin is added to the progessbar (e.g. unit.smallSpacing) could be added to the text right margin as well?

What should we do about this?

The consensus seems to be that we should centre it if it is not feasible to align it to the right properly. 
So if there's not good way to do it, and it seems this way as this bug report is a bit old, we should centre it.

Yup, go ahead and center it. And while we're at it, please change the first letter to lower case.

If I recall correctly, it was moved to align to the right because the text bounced as the seconds passed (because the width of 1 is different to 8, on some fonts).

If you have no solved it any other way, then the text will bounce around on the left side, when aligned to the right. Aligning it to the right does not change this problem.

The only way to prevent this is using a font where each number is equal in thickness, or putting the numbers in a special, fixed sized box and align the rest to said box.

Philip and then still, it may jump when the number changes from singular to plural.

I think the best we can do is indeed just centering the text, it doesn't create any "new jumpiness", and is OK with Andrew.

Martin has a patch at https://git.reviewboard.kde.org/r/122018/diff/

Git commit 8100a067307d9caafeb93b57f927efe5e62eb32c by Martin Klapetek.
Committed on 12/01/2015 at 15:47.
Pushed by mklapetek into branch 'Plasma/5.2'.

[lnf/logout] Center the logout remaining time label

The string capitalization will be done in master/5.3 as we're in string
freeze right now, so this part cannot be changed.

REVIEW: 122018
FIXED-IN: 5.2.0

M  +1    -1    lookandfeel/contents/components/LogoutScreen.qml

http://commits.kde.org/plasma-workspace/8100a067307d9caafeb93b57f927efe5e62eb32c

Git commit ca57135538ee4f505be264472e44bc4df9e0fb7d by Martin Klapetek.
Committed on 12/01/2015 at 15:50.
Pushed by mklapetek into branch 'master'.

[lnf/logout] Change the "in N seconds" capitalization

As per Andrew's design and suggestion

M  +1    -1    lookandfeel/contents/components/LogoutScreen.qml

http://commits.kde.org/plasma-workspace/ca57135538ee4f505be264472e44bc4df9e0fb7d