I noticed improper screen redraws when switching cells while the
window was scrolled down. The drawing logic is pretty conflated
so instead of hunting this down, I have made it so that the full
visible part of the windows gets redrawn each time the user
switches to a different cell.
This is slightly more expensive, but should still be ok.
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.
In order to allow to revert the newly introduced behaviour of putting
transaction text in front of the extracted purpose, the feature can now
be disabled through the preferences dialog.
Some banks include additional purpose information for a transaction in
non-swift-section 17 (aka transaction text). If available, this
transaction text is put in front of the other purpose texts to provide
full transaction information.
While the final solution is still under discussion. This change is a
first low-impact implementation backported and distilled from the work
discussed in gnucash/gnucash#139.
Fixing Bug 779217 increased the maximum denominator by 10, and that led
to overflows when converting large numbers' denominators from 100 to the
new max.
Correct the cell save routine so that the "numeric" kvp is correctly
overwritten in all instances when an edit changes its value for both
credit and debit splits. The both part is accomplished by extracting the
overwrite function.
Also provide a scrub to correct all of the incorrect files.
Unfortunately the necessary calculation function is in app-utils so
running the scrub from the backend as usual isn't possible, so we run it
from gnc_post_file_open in gnome-utils/gnc-file.c instead.
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.
- cleanup whitespace
- add import-pending-matches.c to POTFILES.in
- convert asserts into g_return(_val)_if_fail
- handle the case where no matches are found (which can happen at least in the csv importer and I suspect in the OFX importer as well)
Track pending matches from the current import and display this information in
the match picker.
Conflicts:
src/import-export/gschemas/org.gnucash.dialogs.import.generic.gschema.xml.in.in
src/import-export/import-match-picker.c
https://bugzilla.gnome.org/show_bug.cgi?id=739571
Total Debits Issue re $0 Commodity Accounts and Price Source Mode Set to
"Nearest in Time" or "Most Recent"
There was a silent error from gnc-numeric-sub-fixed in
collect-unrealized-gains because a 0 value wasn't getting its
denominator set in the gnc-numeric-mul call in
gnc:exchange-by-pricedb-helper. While this is ultimately a flaw in
gnc-numeric, this commit works around it by forcing the value to the
correct denom in gnc:make-commodity-collector.
Unfortunately running glade-3 on this file will reorder it completely. So this
commit is only made ad interim to be able to isolate the actual change in the
subsequent one.
