Mike Alexander brought this up with a test case that failed to round down
sufficiently; he found that reducing the rounding denominator by 2 sufficed
to make his test case pass.
In fact the sizing of the replacement denominator by shifting the larger of
the numerator or denominator by an arbitrary 62 bits was not correct most
of the time, so instead we begin with a shift of the full lower leg worth,
try to do the conversion, and if the conversion is still “big” shift the
larger value one more and try the operation again, repeating until the
result will fit in a GncNumeric.
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.
