On Sept. 10, 2013, 7:20 a.m., Allan Anderson wrote: > > Another nice thing would be to have a separate patch for each individual > > functionality. Right now we have two things here 1 - ledger resizing and 2 > > - investment editor fix for widgets that are visible when they should not > > be. For me it's not that easy to make a review this way. > > Allan Anderson wrote: > The two came along together. I can do this for these changes in the > investment editor, but most of the trouble was in the new code, even though > the methods were identical or near-identical. So, for these, there is no > patch fixing something, as there was no code there before. > Anyway, I'll see if I can do some separation. > > Allan Anderson wrote: > Incidentally, this problem with the edit widgets disappearing/appearing > when wanted/unwanted is present in an unpatched git HEAD, and has been there > for a long while. Opening any investment transaction, then resizing the > window, will produce it with one or more widgets. > From some fresh experiments, if a hide() (or show()) does not do the > necessary, then often replacing with setCalculatorButtonVisible(false) and > lineedit()->hide() does the trick. Sadly though, that does not work in > every case, and it looks like the only sure-fire fix is the one I came up > with, setting the widget height to zero instead of hiding. > > > Allan Anderson wrote: > What I'm working on and proposing is, for now, to concentrate on the > column width issues. > It is almost exclusively in the Register class, with revised versions of > Register::adjustColumn(int col) and Register::resize(int col, bool force), > which are much the same as in the original submission. > This will ensure each column is wide enough for its data, so no need (or > ability) for the user to resize any individual columns. Also, at the moment, > while entering or editing a transaction, the width of all the edit edit boxes > is considerably hidden by calculator or date entry buttons. This is > improved, and the number column width can expand while editing, so the user > can actually see all of his entry, instead of it scrolling out of sight. > The whole window may be resized, as now, but I'm abandoning the > long-standing issue of investment edit widgets appearing/disappearing > illogically. > The overall size of the patch is much reduced. > I hope you agree for me to proceed with this. >
Sure, go on, I'm happy with the solution you've described. I'll take a look at the investment edit widgets issue when I can. - Cristian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112364/#review39691 ----------------------------------------------------------- On Aug. 29, 2013, 5:12 p.m., Allan Anderson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112364/ > ----------------------------------------------------------- > > (Updated Aug. 29, 2013, 5:12 p.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/investactivities.cpp 50f33ed > kmymoney/dialogs/investtransactioneditor.h 3e62c2a > kmymoney/dialogs/investtransactioneditor.cpp e9f87fb > kmymoney/dialogs/transactioneditor.h f07dafb > kmymoney/dialogs/transactioneditor.cpp 39049cf > kmymoney/views/kgloballedgerview.h 04a6303 > kmymoney/views/kgloballedgerview.cpp 78d98b2 > kmymoney/widgets/register.h eebe78d > kmymoney/widgets/register.cpp 1bdf5bd > kmymoney/widgets/transactionform.cpp 642e98f > > 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 > >
_______________________________________________ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
