https://bugs.kde.org/show_bug.cgi?id=510377
--- Comment #9 from Simone Iori <[email protected]> --- Created attachment 194614 --> https://bugs.kde.org/attachment.cgi?id=194614&action=edit Columns' resizing behavior (proposal A) Following up on comment #5, where I described the cause: adjustDetailColumn() keeps the columns filling the viewport by giving the whole difference to the detail column, and it does so after every resize, including the user dragging a separator. That is why the detail column snaps back when widened from its right edge, and why dragging a separator to its right moves the detail column's boundary instead of the separator you grabbed. Separators to the left of the detail column feel right because there the correction lands beyond the drag anyway. Three possible behaviors: A. While the user drags a separator, the columns to its right absorb the difference, cascading to the next when one reaches its minimum width; the detail column stays the absorber for everything else, such as the view being resized. B. Always use the last visible column as the absorber. Simpler, but the balance column reaches its minimum almost immediately and the erratic behavior reappears elsewhere. C. Let manual resizes break the fill-the-viewport rule and show a horizontal scrollbar. Predictable, but gives up a deliberate property of the ledger. I implemented A and have been using it. The new attachment shows each separator being dragged in turn: the handle follows the pointer, the columns to its right give way one after the other, and the total stays equal to the viewport, so no horizontal scrollbar appears. Tested in the ledger, payees and tags views, which all share the same code; saved column widths are restored as before. One point of taste: when several columns must give way, I take the width from the nearest one first until it reaches its minimum, rather than distributing it proportionally. Opinions welcome. The split editor has a copy of the same logic with the memo column as absorber and the same problem; I left it out so the approach can be discussed on one focused change first. I will open a merge request with A unless someone prefers a different behavior. -- You are receiving this mail because: You are watching all bug changes.
