
- #Gnucash add ons install#
- #Gnucash add ons software#
- #Gnucash add ons code#
- #Gnucash add ons windows#
Visual Studio 2008 Express was tested and verified to create a executable that can be started, but there are still problems preventing its actual use (see below).
#Gnucash add ons windows#
The sub-project Cutecash can be developed on Windows as well, both by the Mingw compiler (gcc) and by Microsoft Visual Studio. This package is called libqt4-dev on Debian-related distributions. The CMake step will check for the qt4 development package, which is required for building cutecash. Then, change into its top-level directory, create a new empty build directory, change into the new build directory, and run "cmake".
#Gnucash add ons install#
Sudo apt-get install build-essential libqt4-dev cmake By using CMake, you will get a compiled cutecash instead of gnucash.
#Gnucash add ons code#
All code is in current git master the distinction is that normal gnucash uses the autotools/configure build system, whereas cutecash uses CMake. In other words, there is no separate branch or repository with code that isn't already in git master. The source code of Cutecash is available directly in gnucash's Git master branch. This might change as soon as anyone wants to add a large and cool new feature, e.g., related to data import or online banking or multi-user access. Because of this, I would suggest not to think about cutecash as a proposed "replacement" for gnucash right now - unless the way gnucash works is proposed to change in major ways as well. However, this is still a long way from offering the same user experience to our users compared to gnucash. December 2010 update: The cutecash code is able to get the "main features" from a programmer's perspective up and running.

See below for the #Design Decisions which result from these goals. Some of these thoughts have been inspired by the book "Getting Real" by 37signals. We will just make the decision for now and move on.
#Gnucash add ons software#
We might revise the decision later, but then, software has been rewritten many times already, so that's nothing uncommon or to be afraid of. If this second measure still leaves multiple options, we arbitrarily but boldly choose one option for now (like Wikipedia's "Be Bold") and move ahead. If this first measure still leaves multiple options to choose from, we will generously choose the option which promises the most fun during development for us, the developers. In particular, we will radically ignore all requirements which are currently not yet known, or are not based on the user's point of view. Which one out of many possible design options will give the best user experience? Which option will best fulfill the currently known user requirements? This option is what we will implement.

Scratch, in C++ and using the Qt toolkit. But the GUI is rewritten completely new, from

This means the double-entry principles andĪll of the other achievments in the "engine" and xml-backend and eventually 3.2.4 Menu item manipulation by the active tabĪnnouncing a new sub-project in gnucash: The non-GUI parts are re-used in the.3.1.1 Programming Language C++, GUI Toolkit qt4.
