Geert Janssens-4 wrote > I'm afraid I don't understand what you are writing here exactly. What > needs to > be exported in a way that isn't as is ? Isn't your report working in the > state > this is ? > > Also what is the preferred end result ? Is your report intended to > complement > the existing transaction report or to supersede it ? That is, does your > implementation do everything the original report did and some more, or > does it > only do other things from the original report ?
I am exporting functions from the gnctimeperiod-utilities.scm file which are used in the transaction.scm report and will be used in a couple of other reports I have planned. They work for now since I have the file in config.user. This report is intended to replace the original transaction report. I changed 2 or 3 defaults versus the original but if they are changed back the results are exactly the same as the original. None of the original features have been removed. The original version displays transactions between a range of dates which can be sorted on multiple items such as description or account name. This version does that but also lets you consolidate entries so that only one entry is shown which is the sum of multiple entries. It also allows you to use a find or search command to limit the items displayed. It expands the menu selection for the date range to allow the user to select a predefined date range in addition to using the custom date ranges previously available. The most recent addition was to display the output in a multiple column format. Geert Janssens-4 wrote > 1. It introduces loads of new strings. This is fine in itself, however > many of > them are not marked for translation. That should certainly be fixed at > some > point. > > 2. There are lots of small whitespace issues. While this is not really a > problem with your code itself it clutters our version management. I would > really like to see all trailing whitespace removed (unless part of a > literal > string that's split over multiple lines). Also empty lines should not have > any > other whitespace. And preferably stick to spaces for indentation. I know > some > text editors are not really consistent in this and several other scm files > in > our repo don't adhere to this. I prefer to keep these inconsistencies to a > minimum and avoiding them upfront is a very effective method :) Afraid I don't know how to mark strings for translation. I agree a load of them have been introduced. They basically fall into four categories: 1 Strings for selecting a date - the majority of the new strings 2. strings for the find command 3. strings for consolidating items 4. strings for multiple-column display I have attached two new versions of the files which have the tabs changed to spaces and the trailing spaces removed. The transaction.scm file also has added an additional find command for searching in the reconcilition field. transaction.scm <http://gnucash.1415818.n4.nabble.com/file/n4691244/transaction.scm> gnctimeperiod-utilities.scm <http://gnucash.1415818.n4.nabble.com/file/n4691244/gnctimeperiod-utilities.scm> -- View this message in context: http://gnucash.1415818.n4.nabble.com/Re-New-transaction-report-tp4691133p4691244.html Sent from the GnuCash - Dev mailing list archive at Nabble.com. _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
