The preference schema migration collects all schema mutations that can occur
when upgrading to a newer gnucash version. The old gconf to gsettings conversion is
integrated in this system as well. Newer schema mutations will happen based on version
number upgrades though.
The preference that got replaced is "use-theme-colors". Based on discussion in bug 746163
(https://bugzilla.gnome.org/show_bug.cgi?id=746163) and gnucash-docs PR#105
(https://github.com/Gnucash/gnucash-docs/pull/105) this has been replaced with
"use-gnucash-color-theme" with inverted meaning. The old option is kept around for one or
two major release cycles to allow seamless conversion.
The new signature makes it more clear what the purpose and required type of the parent widget should be.
While at it, the info,warning and error dialog code got slightly refactored for better code reuse.
Finally a few more parent widgets were passed in places where a parent was readily available.
This first commit will replace gnc_ui_get_toplevel with two functions
- gnc_ui_get_gtk_window (widget): tries to find the immediate GtkWindow the given widget belongs to
- gnc_ui_get_main_window: looks for the main window that's the final transient parent widget
can be traced back to. In the absence of widget, this will behave as gnc_ui_get_toplevel did
and return the first active or mapped window.
If the splash screen is still availabe when the dialog should be displayed,
make the splash' window the transient parent for this dialog.
In the other case we try to use the front-most main window. While this
works well when calling file->open from the menu, there may not be a
visible main window yet during startup. Since the user can close
the splash before the dialog is due, we may end up with no usable candidate
as parent window.
In that case the dialog will emit a missing transient parent message on stdout.
There's no easy fix for this as users don't want to see an incomplete
main window (see old bug 350993).
The main topic of this bug was already fixed in earlier commits. This commit
handles the minor improvements also mentioned here:
- don't show the menu option for invoice/bill transactions as that doesn't make sense
- don't show the pre-payment line if the selected transaction was one, in this case only set the amount
- allow users to edit lot link transactions via this mechanism as well (which essentially are payments without an explicit payment split)
The way this is implemented is as follows
- if gnucash can deduce a partner from the transaction that partner will be proposed
this works for all transactions that are part of a business transaction already
and will correctly detect pre-existing customer, vendor and employee payments
- if no partner can be deduced gnucash will assume the transaction to be a vendor
or customer payment based on the sign
- in all cases the user can change the partner type in the payment window that's presented
to any of customer, vendor or employee to correct gnucash' suggestion.
When the selected transaction is already involved in a business payment,
propose to Edit the payment instead of Assigning it as a payment.
This is more informative and will help prevent users from accidentally replacing existing payments.
With this commit the 'assign as payment' logic now works as follows:
- if the selected transaction is already linked to an existing payment, the payment dialog
will present this payment again (same partner, post-to account, same selected document(s),
same amount, memo, and transfer account).
- if the selected transaction is not linked to an existing business transaction the logic
will make a best guess as to whether the payment should be for a customer or vendor.
- in both situations if the existing transaction has multiple splits that can be considered
as transfer (or 'payment') splits the payment dialog can't work with it (it can only deal
with one transfer split). In this case the user will be informed that only one valid
transfer split will be retained and the others ignored.
- the other thing the payment dialog can't handle are APAR type splits that are not associated
to a lot at all. In case of transactions not part of a business transaction they will be
silently ignored on the assumptions these were manually entered transactions with the intention
to be linked to business transactions. On the other hand if such a split is part of a transaction
that is also linked to a business payment already, a warning will be issued these splits will
be removed from the new payment.
This happens primarily on Travis. It looks like the shallow clone it makes is missing
tags. So if git describe fails, fall back to only the short commit hash (as we used to do
previously everywhere).
The main changes are
- group version and build information together
- increase size of application icon and name
- A more complete copyright notice (including 'Copyright' and 'GnuCash')
The default gtk provided about dialog widget won't allow for much more customization than that...
Note the build info has been condensed and is now based on 'git describe' which
returns a very concise, yet complete description of a commit starting from
the last tag that precedes it. This info will also be used anywhere else the build info
was displayed from now on, simplifying translations as well.
This will avoid a ninja-build from picking up a config.h generated by the autotools build
(in the root build directory). Picking up the wrong config.h may lead to all kinds of
subtle issues if the autotools run was done with different options than the cmake run.
This effectively replaces the use of GNUCASH_BUILD_DATE with GNUCASH_SCM_REV_DATE.
The latter is extracted from the current commit if building from some kind of vcs
(currently only works correctly for svn and git). The info extracted while building
from vcs is then also added to the dist tarball so it's available when building
from tarball as well (via the file libgnucash/core-utils/gnc-vcs-info.h).
The same date is also used to set the date in gnucash' man page document.
A practical detail: I have changed the substitution variables in the man page template
from @- -@ to ${} so we could leverage CONFIGURE_FILE in cmake. The necessary
related adjustments have also been made to Makefile.am's substitution rules.
intltool-update should be run from the build directory, not the source directory.
If run from the source directory it will omit glade messages that have a context attribute
so all msgids with a msgctxt comment would be missing.
userdata_home is a different directory on each platform we support (default /home/janssege/.local/share on linux for example)
and gnc_userdata_home is normally userdata_home/GnuCash.
These directories may not always exist (yet) in all circumstances, so properly handle
all of these possible situations.
- Remove trailing semicolons. They're not needed in shell scripts
- Don't create default XDG_DATA_HOME (<HOME>/.local/share) the code
should work equally well if that directory doesn't exist and so
not creating it tests another part of the code
- have gnc_validate_directory throw as well in case of a missing directory
that it shouldn't create. This allows to remove 3 other throws
- slightly adjust the error message in case of missing directory
- never migrate when the final directory is a temporary (sub)directory
This reverts commit 48483b1e3d, reversing
changes made to 53fbc6f62f.
This merge was unintentionally pushed to master. This branch still
needed improvements.
While it doesn't fully fix the python bindings, gnucash
now at least doesn't segfault on start up if built with
python bindings enabled. There are still issues to fix though.
On the C side an SCM guile_options object is wrapped in a GNCOptionDB. This is
however a multi-to-one relationship. That is there can be several GNCOptionDBs
wrapping the same SCM guile_options object. This happens for example when
a report is open together with its Options dialog. Both manager their own
GNCOptionDB object while both wrap the same SCM guile_options.
The problem in this bug was caused by a callback function picking the wrong
GNCOptionDB based on the given SCM guile_options object. Which GNCOptionDB
got picked was completely dependent on how g_hash_table_foreach would cycle
through the stored dbs. It appears this is dependent on the in-memory order
of the hash table's values.
By being more selective of which GNCOptionDB we're looking for, this
could be circumvented. The GNCOptionDB we want is the one related to the open
report options dialog. This GNCOptionDB is different from the one managed by
the report tab in that it has callbacks set. So from now on we search for
a GNCOptionDB that wraps the give SCM guile_options and has one particular
callback set.
The utf8 conversion is only used in the Windows specific section so there's no
need to define an overloaded function on std::string in this case.
Also CMakeLists.txt doesn't require the MingW specific library name setting
for boost::filesystem. Just removing the hardcoded one allows the build to
pick the right name up from the Boost_LIBRARIES variable.
To get the after_failure line work, I had to move the inline
build script to a separate script (util/travis-script.sh)
The second script (util/travis-after-failure.sh) will output
LastTest.log for cmake based builds and all files named
test*.log for an autotools based build.
Note: this commit also comes with a delibarate test failure
to illustrate the Travis behaviour. It will be removed in the
next commit.
This will run the different builds in parallel (depending on
resource availability on Travis).
The advantages are
- faster test results
- easier to spot which build type has failed
- shorter test log per build type to parse
Geert Janssens