https://bugs.kde.org/show_bug.cgi?id=510377
Simone Iori <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Simone Iori <[email protected]> --- I can reproduce this on 5.2.2 (Windows) and I believe I can explain the mechanism after reading the code on master. The erratic behavior is not platform- or packaging-related (Flatpak/AppImage make no difference): it follows from how the ledger keeps its total width pinned to the viewport. The ledger is designed to always fill the viewport width exactly, with no horizontal scrollbar. To achieve this, LedgerView designates the Detail column as the "adjustable" column: every QHeaderView::sectionResized signal queues a call to LedgerView::adjustDetailColumn() (see the connect in the LedgerView constructor, kmymoney/views/ledgerview.cpp), which computes delta = viewport width - sum of visible section widths and adds delta to the Detail column. This single mechanism produces two distinct symptoms: The Detail column cannot be resized from its right edge. When the user drags the separator, Qt resizes Detail, then the queued adjustDetailColumn() computes a delta exactly opposite to the user's change and applies it back to Detail. It snaps back within one event-loop cycle, so the drag appears dead or "only works in one direction" briefly before reverting. Dragging separators of columns to the RIGHT of Detail acts on the wrong boundary. Example with the Payment/Deposit (Decrease/Increase) columns: dragging the separator to the right of Payment by +20px widens Payment by 20, after which Detail shrinks by 20 to keep the total constant. All columns between Detail and Payment shift left by 20, so the separator under the cursor ends up exactly where it started — and the boundary that visibly moves is the Detail/Payment one, i.e. the previous separator. The drag is not ignored; its visual effect is displaced leftward, which feels erratic. Columns to the LEFT of Detail (No., Date, Payee, ...) resize normally, because the compensating change in Detail happens on their right and the dragged separator follows the cursor. This asymmetry explains why reports about this issue sound inconsistent. Geometrically there is no minimal fix that makes the dragged separator follow the cursor while (a) the total width stays pinned to the viewport and (b) the absorbing column lies to the left of the drag point. A fix would need to change one of the two constraints, for example: choose the absorbing column dynamically: when the user drags a separator located to the right of Detail, let the last (or next) visible column absorb the delta instead of Detail; or let user-initiated drags break the fill-the-viewport invariant (allowing a horizontal scrollbar or trailing gap), keeping the auto-adjustment only for viewport resizes. Both are UX design decisions rather than bug-sized changes, so I wanted to share the analysis before anyone attempts a patch. I have a short screen recording demonstrating symptom 2 and can attach it if useful. -- You are receiving this mail because: You are watching all bug changes.
