The register is implemented such that the edit widget is read-only and
all keystrokes are filtered by the sheet widget which then directly sets
the appropriate text in the edit widget each time.
The interim fix here is to make the text edit widget temporarily editable
when cutting or pasting text.
A better solution will be to make the edit widget responsible for all
text entry and delegate everything not handled directly to the sheet widget.
This will be for a later commit
Use real widgets instead of custom drawing something
In essence this is a gtkentry with an optional gtkbutton if the current cell
has a popup (like a calendar or account list). The old code went through
several hoops to keep a hidden gtkentry in sync with the custom drawn item
on screen.
There are still a few issues to fix:
- it's not properly themed to fit in the register. This will be fixed after switching to gtk3 (using css)
- right-click menu is wrong. This currenly shows a default copy/paste menu from a gtkentry
it should be changed to show our own full menu
- keyboard events are still handled backwards. The sheet gets a first stab and passes
on what it can't handle to the item edit. In the current implementation this means not
all key strokes the item edit can handle are received (most notably paste is not working).
As with the grid there is no direct interaction possible with the cursor.
It is merely decoration. It does keep track of coordinates so I've made
it a gobject for memory management. The actual drawing of the cursor
frame is now done by the sheet, just like for the grid.
This change also fixes the transparency issue in the cursor.
- drop lots of unneeded complexity
- use cairo instead of gdk_gc to draw
Issue still to fix: the cursor widget has a grey background instead
of being transparent. I'm not sure this can be fixed before switching
to gtk3
There was no added value in it being a full widget. It only served two functions really
- speed draw the visible and non-editable part of a register window
- locating a cell starting from a pixel
Both are used exclusively by the sheet object, so
I have made them private functions of the sheet.
They are still kept in a separate file though for length considerations.
Most are converted to GtkLayout/GtkiDrawingArea widgets as these
most closely approach the GnomeCanvas concept.
This currently builds and runs but has the following issues still:
- item edit isn't drawn properly (margin and offset issues)
- cursor is not handled properly yet
These will be handled in subsequent commits.
Only reducing column size to less than window width needs extra
research. The auto-expansion of the description column is not
propagated to the header so header and body widths can go
temporarily out of sync as of this commit.
This patch simplifies the previous patch so it does not care where the
file is opened from. If it is in the history list and does not exist,
the dialog advises of this and asks if it should be removed from the
list other wise the dialog displays file not found.
The symptom was that in 2017 the PDT->PST transition was set a week
late. The cause was that the timezone lookup function went the wrong
way, finding the *next* timezone rule instead of the desired one because
timezone rules are stored for the year that they start rather than when
they end. Fix reverses the search to find the correct timezone rule.
Commit includes new tests to detect the problem.
At the same time require --std=gnu11 instead of --sdt=gnu99.
This allows us to drop some conditionals is several places. I've
chosen 2.4 as that is the version available in travis, which appears to
be the oldest platform care about. Debian stable has 2.46 in backports,
our windows environment has 2.42
With the piechart in combination with other charts you have to set the
highlighter and cursor show tooltip to false which stops seen errors.
The syntax errors are caused by only removing the duplicated js files
and not the whole path so changed that to remove whole line.
If a file is opened from the history list and does not exist the dialog
advises of this and asks if it should be removed from the list. If a
file is opened from the command line and does not exist, the normal
dialog is used
taxinvoice was throwing an exception when there were taxes on bill entries.
It also did scan the invoice parts to determine if there were taxes and discounts.
When charging entries from bills we need to exclude taxes since the tax
rate of the invoice might be different than that of the bill.
This fixes Bug 776380 - Gross value of bills charged back instead of
net value (https://bugzilla.gnome.org/show_bug.cgi?id=776380)
xaccSplitSetValue and xaccSplitSetAmount round to the denominator found by
get_currency_denom and get_commodity_denom. The problem was that if the
commodity was unfindable because either the split’s parent or account hadn’t
been set (as is the case during loading, because the parent isn’t yet complete)
the returned denominator would be 100000, smaller than the max supported.
That would cause the value/amount to be prematurely rounded.
Guard against recursively calling the account doesn’t exist query or creation
dialog if one is already in the account creation dialog.
The underlying problem is that creating the dialog forces a UI update that
in turn sets the cell value and checks for the existence of the account.
In basic view the cell being displayed (“transfer”) isn’t the one being
changed (“account”) so the account check isn’t invoked, but in
multi-split view the “account” cell *is* displayed so the check is invoked
again.
Since they touch strings and user behavior they cannot go into maint.
The pull request now only includes the backend change. By that you can
easily tweak the invoice reports to show the net price.
Create one gncEntryGetPrice function which can create given price or
net price for both invoices and bills based on option parameters.
The master version of taxinvoice.eguile.scm needs this for bills too.
Add gncEntryGetNetPrice
Create an option in taxinvoice to either use gncEntryGetNetPrice or
gncEntryGetPrice
So far taxinvoice would show net or gross prices dependent on the internal flag tax_included.
This is inconsistent for the reader of the invoice since there is no notion of that flag.
This patch adds the option to always show net prices.
It does not change the default behaviour even if I would consider it broken.
