Using Ledgers, the No. column is not adjustable. This became most noticeable with the advent of online bill paying. Instead of a check number you receive a reference number that might look like "A7XCC-GY9M2". Simply won't fit. Considering the huge amount of real estate devoted to Detail perhaps that could be resized with the space gained then assigned to No. ? Reproducible: Always
*** Bug 321947 has been marked as a duplicate of this bug. ***
Very similar to 321947
Submitted to reviewboard 29 August - https://git.reviewboard.kde.org/r/112364/ Marko confirmed - Tested this on MacOSX. Worked nicely. No problems found.
> Cristian Oneț <onet.cristian@gmail.com> wrote: > Well I don't like the way resizing looks (I can make a short movie) > because the whole ledger flickers like hell :) and I don't like the > way it behaves because: > 1. It's not persistent between runs They way I have implemented it, is to ensure that each column is always wide enough to contain its present data, instead of some columns being clipped and others with too much of the space. So, I don't really see any need for a user to deliberately clip his data or to allocate more space than needed. So, persistence was deemed unnecessary. > 2. It's not persistent between window resizes - I know that you meant > this as a feature but I think that, if the user's intention is to > customize the column widths, it's a pain in the ass because he keeps > loosing all the customization he's done See above. > What I would do to fix the reported issue (the check number has not > enough space) is to improve the column width auto adjustment > algorithm. Which I've done. Anyway, I'm having another look.
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.
Created attachment 82484 [details] The fix that I would apply for this issue Frankly I don't like the patch in the review request https://git.reviewboard.kde.org/r/112364/ because: 1. It's too complicated so it does more then just trying to fix this 2. Because it does more then fixing this it also introduces unwanted behavior and bugs (see my review for more information) I find this patch more simpler and suitable for the current behavior of KMyMoney when long data is entered in the ledger (auto adjust columns after the transaction was entered).
Your patch is certainly simpler. In forms mode , there is not much wrong, but did you look at the register when not in forms mode? With a check account, it is now possible to enter a long number, but while entering a new number, the column only displays about three characters. The Date, Payment and Deposit columns take up too much space, which can clip the Details column. With an investment, the Date, Quantity and Price columns are too wide. When editing an investment, the Quantity column is now too narrow because of the calculator button. On different activity types, some widgets are missing and some are showing unnecessarily, and the flickering on window resize is still there.
Please leave the "widgets are missing and some are showing unnecessarily, and the flickering on window resize" issues for BUG 322768. The fact that "When editing an investment, the Quantity column is now too narrow because of the calculator button" is related and relevant to this issue.
(In reply to comment #8) > Please leave the "widgets are missing and some are showing unnecessarily, > and the flickering on window resize" issues for BUG 322768. Done. > The fact that "When editing an investment, the Quantity column is now too > narrow because of the calculator button" is related and relevant to this > issue. Good. With the Number column, I really don't like being able to see just three characters when entering or editing a number. One user has raised a bug, requiring to be able to enter, say, "A7XCC-GY9M2MM". You really need to be able to see what you've typed, before you accept it, rather than having to come back in. Also, you're not really correct when you said "...to the one [version] which makes the column size change at each key press...". During input, when it becomes necessary to increase the column width, I add three character widths, to reduce column resizing. The 'three' was an arbitrary value, and could be increased further. The number column is not actually the only bug. There is also Bug 321947, although that's from me, but quite few other users have referred to resizing columns. If you agree, i'd like to go back to this, although without the maximum width restriction. It's mostly done.
(In reply to comment #9) > With the Number column, I really don't like being able to see just three > characters when entering or editing a number. One user has raised a bug, > requiring to be able to enter, say, "A7XCC-GY9M2MM". You really need to be > able to see what you've typed, before you accept it, rather than having to > come back in. My argument was the following: if your account already contains transactions with long check numbers you don't have this problem. So you only need to type seeing only tree characters if you are entering the first transaction in an account and you are not using the transaction form. Which, I argued, has a low incidence. Don't you agree with this? > Also, you're not really correct when you said "...to the one > [version] which makes the column size change at each key press...". During > input, when it becomes necessary to increase the column width, I add three > character widths, to reduce column resizing. The 'three' was an arbitrary > value, and could be increased further. I didn't have so much of a trouble with the arbitrary value as with the idea of resizing a column in which a cell is being edited while typing which, from my point of view, is a totally not standard behavior of a table view, please give me an example of an application that does that. > The number column is not actually the only bug. There is also Bug 321947, > although that's from me, but quite few other users have referred to resizing > columns. > If you agree, i'd like to go back to this, although without the maximum > width restriction. It's mostly done. I'm not against requesting a review for anything. If the patch and the behavior it implements is sound I'm not against it. I had two problems with the previous patch in the order of their importance: 1. It was setting a maxim with for the amounts column 2. The resizing while editing in-place which I don't consider a standard behavior
(In reply to comment #10) > (In reply to comment #9) > > With the Number column, I really don't like being able to see just three > > characters when entering or editing a number. <snip> > My argument was the following: if your account already contains transactions > with long check numbers you don't have this problem. So you only need to > type seeing only tree characters if you are entering the first transaction > in an account and you are not using the transaction form. Which, I argued, > has a low incidence. Don't you agree with this? > Personally, for me this is not a problem as, at least at present, my check numbers are six digits, although I have had accounts which contained alpha. This may actually have been a fuss over nothing, as going back to the OP, I suspect his reference number will have been imported. There is still be no way at all at present to have his number totally visible, so all that is needed, at least in his case, is for the column to display the whole content. The rest of the proposed column resizing patch would see to that. <snip> > > I didn't have so much of a trouble with the arbitrary value as with the idea > of resizing a column in which a cell is being edited while typing which, > from my point of view, is a totally not standard behavior of a table view, > please give me an example of an application that does that. > I haven't looked for one. Perhaps I'm an innovator? <BG, really> I'm happy to drop this now. <snip> > > If you agree, i'd like to go back to this, although without the maximum > > width restriction. It's mostly done. > > I'm not against requesting a review for anything. If the patch and the > behavior it implements is sound I'm not against it. > > I had two problems with the previous patch in the order of their importance: > 1. It was setting a maxim with for the amounts column > 2. The resizing while editing in-place which I don't consider a standard > behavior Yes, they go.
As the originator of this wish list item I have enjoyed following the development. Am curious about one factor though. The Details column width is HUGE. How many character spaces is it? My Kmymoney file has been in steady use since 12/30/2005. None of my payees have exceeded 1/4 the width. If a transfer was selected and the "Pay to" was left blank, when the data in Memo took its place, spaces used still didn't reach half way across. Why not take space from it and allocate to No.? The example I submitted is 11 alphanumeric characters minus the quotation marks, "A7XCC-GY9M2". If the column were resized to say 15 it would allow for future variations of a check number to fit. Have doubts that 10 character spacing removed from Details to make this happen would even be noticed. On 09/25/2013 07:34 AM, Cristian Oneț wrote: > https://bugs.kde.org/show_bug.cgi?id=312816 > > Cristian OneÈ› <onet.cristian@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |onet.cristian@gmail.com > > --- Comment #8 from Cristian OneÈ› <onet.cristian@gmail.com> --- > Please leave the "widgets are missing and some are showing unnecessarily, and > the flickering on window resize" issues for BUG 322768. > The fact that "When editing an investment, the Quantity column is now too > narrow because of the calculator button" is related and relevant to this issue. >
Currently the number field has a maximum width of 10 characters. That is removed by the patch I have attached. The discussion I had with Allan covers more than that simple limitation that's why is so long. To answer the questions related to the details field: The ledger column auto adjustment algorithm works in the following way distributing the available width (of the ledger): 1. Compute the necessary width of each column other then the details based on the data it contains 2. Assign leftover space to the details column For the number column step 1 was limited to maximum 10 characters. Removing that limitation will make the algorithm work as expected.
(In reply to comment #12) > As the originator of this wish list item I have enjoyed following > the development. !! Don't worry, we're getting close now. > Am curious about one factor though. The Details > column width is HUGE. Yes, which Cristian has responded to. And other columns had excess space as well, which was not usable elsewhere.
Created attachment 82824 [details] REVIEW:112989 - Improve the resizing of the register and the transaction form. This patch updates Cristian's in REVIEW:112989.
Git commit f3ac957d713585fd5dce0017d764468e80a1950e by Cristian Oneț. Committed on 29/09/2013 at 11:18. Pushed by conet into branch 'master'. Improve the resizing of the register and the transaction form. The transaction form was not correctly resizing the Value2 column when the data of the KMyMoneyEdit exceeded the size of the widget. The size of the push button (when present) was not considered when the width was computed based on the cell text. The same issues were fixed for the inline transaction editor. The register resizing was improved in the following ways: - the number fields is no longer limited - the details column can no longer be shrinked to a size smaller then it's needed to render the data it contains REVIEW: 112989 M +0 -2 kmymoney/widgets/kmymoneydateinput.cpp M +27 -26 kmymoney/widgets/register.cpp M +5 -0 kmymoney/widgets/register.h M +9 -2 kmymoney/widgets/transactionform.cpp http://commits.kde.org/kmymoney/f3ac957d713585fd5dce0017d764468e80a1950e
I was thinking this one had been put to bed, but I think there is still a little problem or two. I'm looking at an investment transaction and the Details column width allows only about 26 characters, partly because the security name is fairly long, and partly because the edit widgets all have empty space where their buttons would appear, were they visible. I had already produced a fairly small fix for this, which hasn't been taken up. Secondly, and following on from the above, If I stretch the window to allow the Details column to expand, the Interest widget flickers quite badly, probably because the split button is misbehaving. With Cristian and Thomas's involvement, I don't want to do anything unless given the OK.
See also "Adjust detail column to maximum available space".
(In reply to comment #17) > Secondly, and following on from the above, If I stretch the window to allow > the Details column to expand, the Interest widget flickers quite badly, > probably because the split button is misbehaving. I'll deal with this in https://bugs.kde.org/show_bug.cgi?id=276322
Been several months now and I haven't received any updates to the status. Fixed or still fighting problems? If fixed please advise how to apply a patch if that is the method used. My OS of choice is Linux Mint 17 and with the latest installation I do not have the capability to resize columns. Thanks Jim On 01/11/2014 05:41 PM, allan wrote: > https://bugs.kde.org/show_bug.cgi?id=312816 > > --- Comment #17 from allan <agander93@gmail.com> --- > I was thinking this one had been put to bed, but I think there is still a > little problem or two. > > I'm looking at an investment transaction and the Details column width allows > only about 26 characters, partly because the security name is fairly long, and > partly because the edit widgets all have empty space where their buttons would > appear, were they visible. I had already produced a fairly small fix for this, > which hasn't been taken up. > > Secondly, and following on from the above, If I stretch the window to allow the > Details column to expand, the Interest widget flickers quite badly, probably > because the split button is misbehaving. > > With Cristian and Thomas's involvement, I don't want to do anything unless > given the OK. >
(In reply to comment #20) > Been several months now and I haven't received any updates to the > status. Fixed or still fighting problems? > > If fixed please advise how to apply a patch if that is the method > used. My OS of choice is Linux Mint 17 and with the latest > installation I do not have the capability to resize columns. > > Thanks > Please see comment #16, where a patch was applied last December. This does not allow user resizing of columns, but the number field now expands to display entered data. The patch is in the development branch in git, and will be included in the next stable release this summer. Otherwise, you would need to compile from git.