Created attachment 113884 [details] screen shot In "Ledger view", date displays full CCYY format but due to width of Date column the last digit is obscured by "details column" and cannot be seen. This could be rectified if either number / date / details column widths could be resized or else if date format were only showing YY (i.e. last two digits). Great program, by the way.
Git commit ce26e771673a1d4f2a3762499556134396ab9369 by Ralf Habacker. Committed on 11/07/2018 at 16:58. Pushed by habacker into branch '4.8'. Fix 'Last digit of date field is obscured by "details column" in ledger view' The setting of the minimum and maximum column header width to the same value has been removed so that the column width can be calculated from the content. FIXED-IN:4.8.3 M +0 -3 kmymoney/views/kgloballedgerview.cpp https://commits.kde.org/kmymoney/ce26e771673a1d4f2a3762499556134396ab9369
Just recognized, that this fix does not help, if the transaction form below the ledger view is used. > In "Ledger view", date displays full CCYY format How do you setup this format ? I cannot enter this format in the KDE regional settings kcontrol module, started inside kmymoney with "settings"->"KDE regional/language settings". The date column in the ledger view uses the regional short date format. If I enter the long format e..g "WOCHENTAG, tT. MONAT JJJJ" I can see that some dates e.g. "Donnerstag, 26. September 6999" in german, the last digit is still hidden. This is because int Register::minimumColumnWidth(int col) there is used KGlobal::locale()->formatDate(QDate(6999, 12, 29), KLocale::ShortDate) + " "); for calculating the date column width. This returning "Sonntag, 29. Dezember 6999" for german language, which is shorter than the longest possible string in german. "Donnerstag, 26. September 6999" In other languages the longest date string may be on a different date.
But we only use ShortDate here which should have a fixed size of 10 chars. Using 6999-12-29 should provide the greatest width with proportional fonts. https://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKLocale.html#aaa95a4db4035832bc7effdf3dc560240abde0ec79d71101aa2be3dabb23a0d197 I am not sure where the LongDate comes into play. The change you made only adjusts the height not the width. The width is adjusted dynamically in void Register::resize(int col, bool force) which calls void Register::adjustColumn(int col) and finally int Register::minimumColumnWidth(int col) which does the calculation.
(In reply to Thomas Baumgart from comment #3) > I am not sure where the LongDate comes into play. In KDE regional settings you have two fields Long date format: e.g. which may be "WEEKDAY DD MONTH YYYY" and Short date format: eg. "YYYY-MM-DD" There is nothing which prevents entering "WEEKDAY DD MONTH YYYY" or "WEEKDAY YYYY-MM-DD" into the short date format field, which is then displayed in the date column of the ledger view. > But we only use ShortDate here which should have a fixed size of 10 chars. > Using 6999-12-29 should provide the greatest width with proportional fonts. which works only for the "YYYY-MM-DD" date format. For any other format string the calculation using the fixed date may not return the longest date string depending on the current language and may hide digits from the date. An example: If the user chooses date format "WEEKDAY DD MONTH YYYY", in german the date for the longest date string "Donnerstag, 26 September 6999" is 6999-09-26, while in english one of the longest string "Wednesday, 25 September 6999" is 6999-09-25. This may differ for other language. From what I can see now, a correct implementation of Register::minimumColumnWidth() should get the longest date string for the current language by iterating all dates for a whole given year once at application start and use that for the date column minimal width. >The change you made only adjusts the height not the width. This is funny: removing the two rows has already adjusted the width of the date column to the contained date but had no influence on the height.
(In reply to Ralf Habacker from comment #4) > >The change you made only adjusts the height not the width. > This is funny: removing the two rows has already adjusted the width of the > date column to the contained date but had no influence on the height. Vertical resizements are performed in Register::updateRegister() register.cpp:980: verticalHeader()->resizeSection(i, item->rowHeightHint());
> From what I can see now, a correct implementation of> > Register::minimumColumnWidth() should get the longest date string for the > current language by iterating all dates for a whole given year once at > application start and use that for the date column minimal width. I would only iterate over the weekdays and the months. That leaves 19 iterations instead of 365/366.
(In reply to Thomas Baumgart from comment #6) > > From what I can see now, a correct implementation of> > > Register::minimumColumnWidth() should get the longest date string for the > > current language by iterating all dates for a whole given year once at > > application start and use that for the date column minimal width. > > I would only iterate over the weekdays and the months. That leaves 19 > iterations instead of 365/366. This only returns the correct string length if the user really enters'WEEKDAY' and'MONTH'. In any other case, the string length is too long. To avoid this, a kind of parser would be required to be able to choose over which elements to iterate. Note that there is no control over what the user enters in the short date field. To avoid this, I iterate over all days of a year, which takes about 2 ms at program start.
(In reply to Thomas Baumgart from comment #6) > > From what I can see now, a correct implementation of> > > Register::minimumColumnWidth() should get the longest date string for the > > current language by iterating all dates for a whole given year once at > > application start and use that for the date column minimal width. After looking much deeper into the implementation of this method I recognized that the implementation in fact limits the maximum string length instead of the minimum length, which requires determining the longest date string. Fixing the implementation obsolates that approach.
Git commit b565ce018e5f484e0bceb890992976a189f755b9 by Ralf Habacker. Committed on 16/07/2018 at 13:52. Pushed by habacker into branch '4.8'. Fix hidden digits from the date column when using the transaction form in the ledger view and longer short date format setup The problem was caused by an incorrect calculation of the minimum width of the date column (in fact, it has previously limited the maximum length instead of the minimum length). FIXED-IN:4.8.3 M +3 -4 kmymoney/widgets/register.cpp https://commits.kde.org/kmymoney/b565ce018e5f484e0bceb890992976a189f755b9
*** Bug 382621 has been marked as a duplicate of this bug. ***
Git commit 0a0b0cfbd0adbdf6c88249f3020b4f984f3eda91 by Thomas Baumgart. Committed on 07/10/2018 at 06:21. Pushed by tbaumgart into branch '5.0'. Fix width of date edit widget Fix hidden digits from the date column when using the transaction form in the ledger view and longer short date format setup. This is copied from commit b565ce018e5f484e0bceb890992976a189f755b9 M +1 -2 kmymoney/widgets/register.cpp https://commits.kde.org/kmymoney/0a0b0cfbd0adbdf6c88249f3020b4f984f3eda91