A: Yes. Starting with release 2.2.0, is also available on Windows.
Other related options would be colinux, VMWare and a windows-based X-server hosting a remote session.
A: This was probably true at the time when 1.6.0 was released. It is no longer true today, as almost every distribution ships with all the necessary libraries (except g-wrap, which means there is in fact “one” extra library to be installed before compiling ). However, by default, distributions wont install the development packages of the required libraries, so you might need to start your distributions installer program and tell it to install not only the library packages but also the -devel packages. In general, it was noted that this problem concerns many applications in the gnome domain, and this also boils down to the fact that there is no such thing as “one monolithic gnome package”.
A: No, for now must be run interactively.
A: You can have multiple people with access to the same datafile, but they cannot use the data file simultaneously.
To setup multi-person access, all the people must have read/write access to the directory containing the file (to read the others created files, and to create new files). One way to do this is by creating a user group and setting the data directory to be owned by the shared group and set to mode 2775. The “2” makes the directory setgid which copies the permissions to all files.
A: The core functionality of is written in C, but do not forget that much of this can be accessed through Guile (scheme). There are a number of reasons for why
is written in C. The first is historical,
was started in 1996 (or maybe even earlier!) and many of the OOP (C++, Java, Python) compilers were not yet mature and standarized enough on the variety of platforms considered at that time, so C was the only option at that time. A second reason is because the standard GUI
uses is GTK, which is written in C.
A: The quick answer is “We wont”. The longer answer is complex but still amounts to “We wont”. is a large body of code maintained by a small group of developers who are comfortable in C and Scheme (Guile). Actually, 80% of it is in C and approx. 13% is in Scheme/Lisp. There is no valid reason that would justify rewriting this amount of existing code in a newer language. Also, creating language bindings to recent languages such as Python or Ruby or (insert your favourite language here) is labor intensive, and were already stretched pretty thin maintaining and developing the existing code.
Having said that, this is an open source project and youre free to do with it or contribute what you want. Just dont expect much support if the reason for your changes is that youre not willing to learn C or Scheme. Also, used to have SWIG bindings (http://www.swig.org) which have been used for some perl programming code. According to a list discussion, these SWIG bindings might still be a way to include other languages into
, but currently they are unused and unmaintained.
A: Ask nicely. :-) You can file an enhancement request at http://bugs.gnucash.org/enter_bug.cgi?product=. Please bear in mind to describe your proposed enhancement as verbosely as possible. The trick here is to learn how to give the best information to the programmers about what your proposed new feature should do. If you want to speed up development significantly, consider donating some money as described on Development.
A: Were working on a more formal process, but for now you should subscribe to the mailing list at http://lists.gnucash.org/mailman/listinfo/gnucash-user and http://lists.gnucash.org/mailman/listinfo/gnucash-devel and discuss what you can contribute with the participants on the lists. Please be aware that is a large body of code written in C and Scheme (see the FAQ above, “Why is
written in C?” if you want to know why). If these are languages that you are not willing to work with, consider contributing in other ways.
A: First of all, try to verify that it is indeed a bug and that it has not been reported before. Search the mail list archives (see FAQ above). Then search the Bugzilla database.
If you feel you have indeed found a bug, you can then report it at http://bugs.gnucash.org/enter_bug.cgi?product=. Please bear in mind to report your bug as verbosely as possible. The trick here is to learn how to give the best information to the programmers about how to reproduce bugs. A Programmer will usually only be able to fix a bug they can see, if you cant make the programmer see your bug, it wont get fixed!