Difference between revisions of "Cutecash"
(add vision) |
(→Vision: add design decisions so far) |
||
| Line 15: | Line 15: | ||
=== Vision === | === Vision === | ||
| − | This finance software will be developed with the following two goals: | + | This finance software will be developed with the following two goals in mind: |
# Create the best possible user experience in a finance management software | # Create the best possible user experience in a finance management software | ||
# Have the highest possible amount of fun during development | # Have the highest possible amount of fun during development | ||
| − | Because of this, design decisions during development will have to be measured firstly by the point of view | + | Because of this, design decisions during development will have to be measured firstly by the user's point of view, and radically so. 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. No more, no less. 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. |
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. | 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. | ||
| Line 25: | Line 25: | ||
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. 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. We will just make the decision for now and move on. | 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. 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. We will just make the decision for now and move on. | ||
| − | Some of these thoughts have been inspired by the book "Getting Real" by 37signals | + | Some of these thoughts have been inspired by the book "Getting Real" by 37signals. See http://gettingreal.37signals.com for an on-line copy. |
| + | |||
| + | ==== Example Decisions ==== | ||
| + | To add some concrete examples for design decisions already taken: | ||
| + | * Implementing a New-File-Assistant is a crucial component to achieve a good user experience, and in this area gnucash is a good role model. Hence, Cutecash will have a New-File-Assistant which will be an almost one by one copy of the gnucash one (but this is one of the seldom places where this happens). | ||
| + | * Not adding a plugin framework (you know, loading all sorts of features at run-time) will for sure be one outcome of the first measure. There is simply no benefit for the user in that. Really. Zero. All enabled or disabled features are known at compile time, so they will be statically compiled-in and that's that. (One out of several technical reasons for that: The translation framework would turn significantly more complex if other plugins were supplied in separate packages, as they would have to supply their own translations in all languages of the main package. Alternatively, the plugin features would suddenly not be translated whereas the main program is, and nobody wants that.) Hence, we won't have it in Cutecash. | ||
| + | * The programming language for the GUI is irrelevant to the user, so the first measure doesn't weight any choice higher than another. However, for the developer fun it is a must-must to program the GUI in anything BUT C. C is nice for low-level stuff, but today (!) this is just plain wrong to use it for GUI programming. I mean, you also don't manage your hard disk by keeping a table of the nodes by yourself; instead, you use a file system on the hard disk. So for the development fun we must choose a different language for the GUI programming. I ([[User:Cstim]]) happen to have a lot of experience in C++ and it also enables very simple integration of the lower level C parts of gnucash, so that's what I chose for now. | ||
| + | * Same reason for choosing the Qt GUI framework: For the user it's irrelevant. Technically, several others would be viable options as well. Qt IMHO has the best documentation around, and it comes with qt-designer for easy GUI design, and I ([[User:Cstim]]) happen to know it very well. So that's what I chose for now. | ||
==Build Instructions== | ==Build Instructions== | ||
Revision as of 14:12, 5 March 2010
Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.
Contents
Cutecash. Easy to develop, easy to use
Announcing a new sub-project in gnucash: The non-GUI parts are re-used in the state they are, in the C language. This means the double-entry principles and all of the other achievments in the "engine" and xml-backend and eventually other backends can be re-used. But the GUI is rewritten completely new, from scratch, in C++ and using the Qt toolkit. Fun again. The build system is CMake because its configuration runs magnitudes faster. Fun again. And as a final bonus, for MS windows more compiler than before are supported, namely this whole new project can be compiled by MS Visual Studio as well.
http://lists.gnucash.org/pipermail/gnucash-devel/2010-March/027700.html
Vision
This finance software will be developed with the following two goals in mind:
- Create the best possible user experience in a finance management software
- Have the highest possible amount of fun during development
Because of this, design decisions during development will have to be measured firstly by the user's point of view, and radically so. 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. No more, no less. 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.
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.
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. 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. We will just make the decision for now and move on.
Some of these thoughts have been inspired by the book "Getting Real" by 37signals. See http://gettingreal.37signals.com for an on-line copy.
Example Decisions
To add some concrete examples for design decisions already taken:
- Implementing a New-File-Assistant is a crucial component to achieve a good user experience, and in this area gnucash is a good role model. Hence, Cutecash will have a New-File-Assistant which will be an almost one by one copy of the gnucash one (but this is one of the seldom places where this happens).
- Not adding a plugin framework (you know, loading all sorts of features at run-time) will for sure be one outcome of the first measure. There is simply no benefit for the user in that. Really. Zero. All enabled or disabled features are known at compile time, so they will be statically compiled-in and that's that. (One out of several technical reasons for that: The translation framework would turn significantly more complex if other plugins were supplied in separate packages, as they would have to supply their own translations in all languages of the main package. Alternatively, the plugin features would suddenly not be translated whereas the main program is, and nobody wants that.) Hence, we won't have it in Cutecash.
- The programming language for the GUI is irrelevant to the user, so the first measure doesn't weight any choice higher than another. However, for the developer fun it is a must-must to program the GUI in anything BUT C. C is nice for low-level stuff, but today (!) this is just plain wrong to use it for GUI programming. I mean, you also don't manage your hard disk by keeping a table of the nodes by yourself; instead, you use a file system on the hard disk. So for the development fun we must choose a different language for the GUI programming. I (User:Cstim) happen to have a lot of experience in C++ and it also enables very simple integration of the lower level C parts of gnucash, so that's what I chose for now.
- Same reason for choosing the Qt GUI framework: For the user it's irrelevant. Technically, several others would be viable options as well. Qt IMHO has the best documentation around, and it comes with qt-designer for easy GUI design, and I (User:Cstim) happen to know it very well. So that's what I chose for now.
Build Instructions
Linux
On Linux, install qt4 (>= 4.5.0) and CMake (>= 2.6.0), grab the gnucash sources from SVN, change into its top-level directory and run
mkdir build-cutecash cd build-cutecash cmake .. make ./src/gnc/cutecash
The qt4 development package is called libqt4-dev on Debian-related distributions.
Windows / MSVC
The sub-project Cutecash can be developed with the Microsoft Visual Studio compiler (MSVC) as well. Visual Studio 2008 Express was tested, but others might work as well. However, the Cutecash project needs a large number of dependency libraries which are not built by MSVC, but by the Windows-Mingw compiler (gcc).
The recommended process goes as follows:
- Let the dependencies be build by the mingw installation process which is being used for the "normal" gnucash, explained here: Windows, in particular Windows#Instructions_for_an_.28almost.29_automated_build
- Once all of this is built, you start CMake from http://www.cmake.org. Select the top-level folder of the gnucash source code as source folder; select some new empty folder as build folder. Then click "Generate" and choose a "Visual Studio 2008 project". Subsequently, you will have to select some header file locations and library locations until CMake does not complain about anything anymore, but those have all been installed by the automatic build from Windows#Instructions_for_an_.28almost.29_automated_build
- Next, you open the MSVC2008 project file that was created by CMake, then build this project. The resulting executable can be run and built again and debugged and developed in the normal Visual Studio way.
