There were several problems since the conversion to gtk3
* widget wasn't displayed at all - apparently this was because I had overriden the draw function of the gtklayout (sheet)
-> fixed by adding a draw callback instead
* several gtk warnings about allocating sizes to widgets without using *get_preferred_width/height
-> fixed by adding the itemedit dropdowns to the layout only when they are requested
* the arrow button didn't want to resize small enough
-> fixed by adding a custom style to drops the button's internal padding
* there were several sizing issues which ironically got fixed dropping much of the custom sizing code
gtk_statusbar_set_has_resize_grip
gdk_drawable_get_screen
gdk_device_get_core_pointer
There is no replacement for it in gtk3 and it's probably
not needed any more either.
The old code directly accessed a member variable of GtkEntry. This
direct access is no longer possible, but there is no public function
to get/set this variable. There is a private one used by
GtkComboBox internally) but it's not exported so it can't be used either.
As an interim solution I peeked at how hesiod handled it in his earlier
(unmerged) gtk3 branch. He replaced this private access with setting
gtk_widget_set_visible, something I wouldn't have considered in this
situation. The issue is in the register2 code, so for now it's not
too important. We can investigate this more when the register rewrite
is picked up again.
Only gnc-dense-cal.[ch] is left untouched because it's use
of color is tightly coupled to the use of GtkStyle. This
latter needs conversion as well, but would be too much to
add in one commit.
Additionally the register code uses GtkStyle to extract
colors. This has been partially converted to using GdkRGBA
with the inconvenient side effect that depending on how
a color is retrieved it has to be freed with gdk_rgba_free
or not. This may be cleaned up later.
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.
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
