cmake:
- add test-app-utils
- rename test-link-module to test-link-module-app-utils
- add gtest-import-map
autotools:
- move gtest-import-map from TEST_PROGS to TESTS (autotools) so it shows up in the colored results list
While I myself asked for it to be retained a couple of years back
I now believe it really makes no sense to keep on carrying
a completely outdated rpm spec file around. This should not
be part of the source and properly up to date and maintained
rpm spec files can be found in each rpm based distro that ships
gnucash.
It is split into
- /libgnucash (for the non-gui bits)
- /gnucash (for the gui)
- /common (misc source files used by both)
- /bindings (currently only holds python bindings)
This is the first step in restructuring the code. It will need much
more fine tuning later on.
These are currently unmaintained, cutecash us based on the obsolete qt4
and gtkmm is only used by cutecash. Whenever someone wishes to revive
this experiment it can be recovered from git history and be brought
into a separate repository.
The resolves it's 'allmost nongui' status. Note the options code still
stores a pointer to a gtk widget but this is never used in the app-utils code
itself. This was already so before this commit and fixing this will require
more refactoring later on.
This commit also aligns the list of non-gui source directories between
cmake and autotools. This may need further tweaking in the context of
splitting the source in libgnucash and gnucash (the application)
They are both about handling core gnucash objects. Qof was once split out
in an attempt to make it a separate library. This hasn't worked out so there's
no good reason any more to keep this artificial separation.
A few considerations:
- The qof tests are merged into the engine test directory but they are kept as
a separate test entity for now. Several assumptions made in the qof tests
are no longer valid in the context of the engine. (For example if the
pricedb test is added in the same test executable as the qofbook test,
the book creation test fails because it now has 2 collections (pricedb and
book) instead of only one. There are plenty of others like this so merging
the tests needs more careful review and is perhaps best done while converting
to c++/Google test.
- I had to use unique names for the MockBackend classes because apparently the tests were
using a MockClass from another file in the cmake builds, causing several
tests to fail.
This adds unnecessary overhead and also serves as an initial experiment
to greatly reduce the gnc-module based modularization.
Oh, and it fixes the autotools make check failure in standard-reports
which I introduced in the previous commit. The fix was to either
fully gnc-modularize business reports or to go to de-gnc-modularize
standard-reports. I chose the latter as I don't want to add any new
gnc-modules any more at this point.
This is half of the work to align the cmake and autotools generated dist tarballs.
What's missing in the cmake dist tarball on my system are all the files generated
or installed by running autogen.sh. I can't test this because cmake can't run
my version of automake (1.15), or at least our CMake configuration prevents this from happening.
- We actually don't care about the available icon sizes so stop checking for them.
- Even if an icon isn't found continue (with a warning). Gtk uses a fallback icon in most cases.
They are now all stored in a directory structure similar to the final
installation target, so no more copying of images during build is needed.
Both Makefile.am and CMakelists.txt behave the same now.
Some additional cleanups:
- move stock_move related images to art; they aren't used so don't need to be installed
- clean up icon loading
There is one harmless warning still at run time about not all requested image
sizes being found. This is odd because they are all installed. I suspect gtk
no longer searches for these resolutions. Perhaps we just shouldn't run the
check on them. The application works fine even without the images in the
requested resolution.
While new files will use CURRENCY to indicate a commodity is a currency,
older files (including our ancient test files) are still using
ISO4217. So we need to expect both values in the xml file tests.
This is different from file loading (which will automatically map
ISO4217 to CURRENCY) and file saving (which will from now on always
write CURRENCY).
Relax the account type change restrictions again. In the new implementation
account types can't be changed for an account with splits:
- if the change woud force a commodity change (to/from normal accounts from/to stock related accounts)
- for immutable accounts
At the time of this commit the following account types are considered immutable:
- Accounts Receivable
- Accounts Payable
- Trading accounts
There is now a separate GNC_COMMODITY_NS_ISO_GUI label to be used
everywhere the users needs to read 'Currency namespace'. It's currently
set to 'Currencies' and can be translated. It may change in to future
to better describe this namespace is restricted to ISO4217 defined
currencies as opposed to all the non-formal currencies in vogue today
(like bitcoin and friends).
Note the operands are const GncDate& because the GncDate has no copy
constructor/assigment operator (any other definition would fail
when used with variables of type boost::optional<GncDate>)
This required a couple of tweaks to the tests because:
- the invalid date returned for impossible conversions is different between the old implementation and the cpp edition
- unhandled glib warnings caused the tests to abort
This double free happened after the introduction of a class variable (static member variable
to GndDate and the test compiling in gnc-datetime.cpp *and* at the same time linking to
gnc-qof. This apparently threw off internal memory management. Removing either of linking to
gnc-qof or compiling in the source file solved it.
Credits go to John Ralls for debugging this.
For some reason gnc-vcs-info.h isn't found properly any more although
the relevant parts of the Makefiles haven't changed compared to the
maint branch. Perhaps a compiler option has changed ? Anyway simply
adding its path explicitly does fix it.
As a GncDate doesn't have any time information, this has to be made up.
GnuCash uses 3 times-of-day quite a lot:
- start-of-day (00:00 local time)
- end-of-day (23:59 local time)
- neutral time (10:59 utc, chosen to minimize
day offsetting when converting to/from localtime)
A second parameter to the new constructor will tell it to use one of these presets.
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.
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.
Geert Janssens