This was producing a date corresponding to 01-01-1970. make-zdate was
being used in aging.scm as a hack to search all splits prior to
end-date. fix the date query logic to set begin-date match to #f.
There is no spacing between the text and the frame in the dialog
"New File" > "New Accounts Hierarchy Setup". In some cases - when
changing the window size - the text appears next to the frame.
It does not look very clean. As a solution, I have defined here a small spacing: 5px.
Really use all splits of any given day. Up to now usually the splits
of the given date were not or not all included, as the time comparison
didn't correctly ignore any given time-of-day of the splits. Instead,
all possible time-of-days should be included.
The subtotal summary-grid will tabulate subtotals - prime-sortkey
vertically, sec-sortkey horizontally. This will be useful, for
example, with prime-sortkey = accounts, sec-sortkey = date,
sec-subtotal = monthly... will produce a monthly time series
spreadsheet.
Introduces grid datastructure.
This is a simple list, each element is a vector
(vector row col data).
In the Transaction Report, row and col are defined
as a pair (cons sortvalue subtotal-heading), whereas:
- sortvalue = string/number used to sort the grid headers,
- subtotal-heading = string used as grid header row/col
- data = the gnc-monetary collector.
Context: https://wiki.gnucash.org/logs/2018/02/24.html#T05:43:50
Summary: I had formerly set some multichoice values to be a list.
However I think options.scm cannot handle list values. They must be
scheme symbols. It wasn't clear to me during TR refactoring and
development.
The root cause is in options.scm multichoice handling, whereby it's
trying to compare the option value with (eq?); in scheme (eq? (list
"A") (list "A")) is always #f.
06ad55cae9/libgnucash/app-utils/options.scm (L911)
is the relevant old code.
Found with -Wimplicit-fallthrough, but older versions of GCC don't support it. So it will take some effort to add it to the build config.
I think it did not result in a reproducible bug.
When the register is obscured by another window, the sheet would get
lot of draw events. This was tracked down to getting the foreground
colour for the item-edit widget for the state GTK_STATE_FLAG_NORMAL.
Changed this to use the value obtained from gtk_widget_get_state_flags.
In a previous commit I wrongly believed xgettext might not find
our strings if we used the fully namespaced boost::locale::translate or
aliased bl::translate instead of just translate. However that's
wrong, so I have changed the code to always use bl::translate.
There is now a directory for each respective file type directly in the gnucash source directory
(This was already started for gschema files before).
In principle all files of each type should go into these global directories. The only
exception is if such a file belongs to an optional module. In that case the file
remains located inside that module's directory. Currently we have ui, glade and gschema file
exceptions in aqb and ofx importers.
As part of this also:
- Drop POTFILIES.ignore. Relevant lines have been moved to POTFILES.skip
- Remove skip lines for scm file links. With intltool out of the way these are never picked up any more.
By default we require gettext 0.19.6 as this is needed to generate a translated version of gnucash.desktop and gnucash.appdata.xml.
However this version is not available on some platforms (most notably our own ubuntu 14.04LTS travis instance).
By setting ALLOW_OLD_GETTEXT=ON, the build configuration falls back to generating untranslated versions of said files instead.
At present these are
- log.conf
- config-user.scm (previously config.user-2.0)
Implement one-time migration of these files to the proper directory if they previously exist
Look for a log.conf file in gnc_userconfig_dir instead of gnc_userdata_dir
Note this commit also uses boost::locale::translate for the first time.
We may need to fine-tune our use, but in the current state strings marked
for translation using that function are already picked up for gnucash.pot.
Turns out the stream facet parser is really slow. Since we have a
well-constrained universe of input formats we don't really need that
overhead. This got a 33% improvement in loading a large SQLite database.
