When the cell borders are not displayed, the border colour is set to
the background colour so test for the widget being in an insensitive
state to get the correct background colour.
For each subclass, getting rid of GNC_SQL_OBJECT_BACKEND_VERSION which
was a bit misguided.
Also remove the bogus test the skipped loading a table if its version
didn't match GNC_SQL_OBJECT_BACKEND_VERSION which was even more misguided.
glib-compile-resources lists the resource files as absolute paths,
but SET_LOCAL_DIST expects relative paths; the result was that the
tarball code was looking for ${CMAKE_SOURCE_DIR}/${CMAKE_CURRENT_SOURCE_DIR}/foo.
This change strips off ${CMAKE_CURRENT_SOURCE_DIR} from the filenames
before passing them to SET_LOCAL_DIST.
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.
If you right mouse on the dense calendar, the treeview pops but also
the rename page popup. So stop the cascade of the button press event
when on the dense calendar.
If there are no marked days in the dense calendar add a blank one. Also
make sure all pending events are processed be fore returning as the
treeview did not always populate correctly.
Commit 88b8477 on libdbi calls the error handler if one attempts to run
off the end of a result set. Since we often loop on
dbi_result_next_row() returning 0 this breaks our logic in several
places. This change simply returns from the error handler on a
DB_ERROR_BADIDX allowing the logic to work as before.
I.e., remove the shell invocation and with it the need to set the shebang.
Surprisingly this required some build-system modifications particularly
for cmake in order to correctly set the environment.
Specified bar colors only apply to positive bars in the plot.
Negative bars still have the default colors, which are slightly
darker shades of the default positive colors.
This commit forces negative bars to have the same colors as
positive bars.
By using CSS classes, there is no need to have separate handlers for
the foreground and background colours so replace them with one being of
a similar format to that of cell_border_handlers.
When the cell borders are not displayed, the border colour is set to
the background colour so test for the widget being in an insensitive
state to get the correct background colour.
With these changes the button image is removed and you are left with
the arrow and frame on the yellow background. This can be dropped or
adjusted if it was deemed a good idea.
There did not seem to be an easier way to control the toggle button
width so created a custom one based on the GtkToggleButton. This
allowed the use of the class function get_preferred_width which is set
at two thirds the height.
When you specify a font size for the sheet, the popup will inherit this
but when first popped it will use the minimum height value and so may
be different resulting in not being in the right position. So check on
allocation and if different remove and pop again.
