make column sizes more stable
Needs RevisionPublic

Authored by mkoller on Mar 28 2020, 4:11 PM.

Details

Reviewers
mlaurent
dfaure
Summary

I have the problem that on every start of kmail, the first column gets a pixel more than before, leading to my "date" column becoming smaller and smaller.

To fix this, it seems to be enough to ensure that when the columns take their sizes from the widget, to keep the fractional part of the column widths.
E.g. after the auto-calculation of the widths a column might have 100.3 pixels in width, however the .3 fractional part is lost when the column width is taken from the widget since the widget only stores int values.

Test Plan

Started kmail several times and checked via kruler and kmag that the columns kept their size exactly

Diff Detail

Repository
R94 PIM: Message Library
Lint
Lint Skipped
Unit
Unit Tests Skipped
mkoller created this revision.Mar 28 2020, 4:11 PM
Restricted Application added a project: KDE PIM. · View Herald TranscriptMar 28 2020, 4:11 PM
Restricted Application added a subscriber: kde-pim. · View Herald Transcript
mkoller requested review of this revision.Mar 28 2020, 4:11 PM
dvratil added subscribers: dfaure, dvratil.

I think @dfaure has touched exactly on this issue before.

view.cpp
607

Make it const double, please

dfaure requested changes to this revision.May 3 2020, 8:14 AM

I trust your testing, but I don't understand the logic of the fix.

  1. losing the fractional part shouldn't lead to losing 1 pixel on every start. 100.3 becomes 100, but then 100 remains 100. Can you explain why 100 would become 99 or 101?
  1. Am I right in assuming that col->currentWidth() != header()->sectionSize(idx)? Otherwise the whole line of code is a no-op.

In that case, if a column has been resized from 253.3 to 100, what sense does it make to save this as 100.3?

This revision now requires changes to proceed.May 3 2020, 8:14 AM