[Kmymoney-devel] Review Request 112364: BUG:312816 - Implement resizing of ledger Number column (and others)., and Interest category and amount disappear when new fee entered in Dividend.

[Cristian Oneț]

> On Sept. 25, 2013, 3:21 a.m., Cristian Oneț wrote:
> > I would not ship this patch. I'll elaborate a bit more my comments at https://bugs.kde.org/show_bug.cgi?id=312816#c6 and I'll base my arguments on this recording I made http://kmymoney2.sourceforge.net/screencasts/112364.ogv about how this patch behaves.
> > 
> > 1. It breaks with the current behavior of the application (auto resizing columns after data has been entered to fit the entered data)
> > 2. It introduces bugs, I mean, setting a maxWidth of "9,999,999.00 " for the amount fields!? This is exactly what was hurting the number column and the fix should be all about removing a limitation not adding new ones
> 
> Allan Anderson wrote:
>     You've concentrated on forms mode, where there is not much wrong.
>     
>     1. Depending on content, there was some clipping.
>     2. There already was in Thomas's implementation a width restriction for the number column, so I eased it substantially.
>     
>     The existing excessive width of some columns can result in clipping elsewhere.  There are still problems with non/unnecessary appearance of investment widgets.
>

I know that the problem with unnecessary widgets is still there, I thought you are working on that (see the discussion with me, the patch I sent you, your discussion with David). We should still fix that issue. I thought that this review request (patch) only handles the number column issue (BUG 312816) at least the latest version of the patch.

I just tried to show that the patch does more damage than good, I agree that there are some issues now but they should be fixed in a proper way so that we don't break current behavior. I'm sure that all those issues that you've observed with the investment editor without the transaction form can be fixed while keeping the current behavior of the transaction form.

With the patch I attached to BUG 312816 I agree that the first time a long check number is entered the user will not see it entirely, but, after the transaction is entered the width of that column is adjusted to fit the entered data, thus next time the user will not have this issue when entering a similar check number. I prefer this, you could say, sloppy implementation because of it's very small incidence to the one which makes the column size change at each key press (with a big incidence).


- Cristian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112364/#review40732
-----------------------------------------------------------


On Sept. 25, 2013, 10:48 a.m., Allan Anderson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112364/
> -----------------------------------------------------------
> 
> (Updated Sept. 25, 2013, 10:48 a.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Description
> -------
> 
> If I choose to use a complex system for check numbers, such that the whole number is not visible,
> the only way I have available is to stretch the whole window. However, even that doesn't help,
> as the whole of the increase is grabbed by the Details column.  I accept that it is likely that that
> column is going to need to be the widest.  Then, why are the Payment and Deposit columns twice the
> width of the Balance column, when that column may be likely to have the greatest value?  Ditto for
> the Date.
> 
> This fix allows modification of column widths, but also resizes the individual columns to more suitable widths.
> 
> I found that Thomas had started to implement something similar some while ago, so I have built upon and expanded that.
> 
> I found that the edit widgets were particularly troublesome, in failing to appear/disappear with the show() and hide()
> methods, which I'd previously found when last in this area. Then, when the screen was being resized, they flickered
> more than acceptable. Eventually, where necessary, I resorted to zeroing/resetting the height instead, which resolved
> the issue, although with some complication.
> 
> 
> This addresses bugs 312816 and 322768.
>     http://bugs.kde.org/show_bug.cgi?id=312816
>     http://bugs.kde.org/show_bug.cgi?id=322768
> 
> 
> Diffs
> -----
> 
>   kmymoney/dialogs/transactioneditor.h f07dafb 
>   kmymoney/dialogs/transactioneditor.cpp 39049cf 
>   kmymoney/views/kgloballedgerview.cpp 2057b47 
>   kmymoney/widgets/register.h eebe78d 
>   kmymoney/widgets/register.cpp 1bdf5bd 
> 
> Diff: http://git.reviewboard.kde.org/r/112364/diff/
> 
> 
> Testing
> -------
> 
> Extensive editing of sample files, and changing back and forth between different activity types, which tended to show
> problem areas. atype run.
> 
> 
> Thanks,
> 
> Allan Anderson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20130925/2d63e4ff/attachment-0001.html>