diff --git a/Docs/projects.html b/Docs/projects.html
index d7676b3a91..34c8af4410 100644
--- a/Docs/projects.html
+++ b/Docs/projects.html
@@ -18,10 +18,10 @@ accounting application. The project goals are to create a world-class
GPL'ed Open Source personal financial application for GNU/Linux and other
Unix's. The project is the result of a merger
of the GnoMoney project with Xacc development. There are currently
-two versions: xacc-1.0.17, and xacc-1.1.x. The version 1.0.17
+two versions: xacc-1.0.18, and xacc-1.1.x. The version 1.0.18
is written in Motif, and is considered to be stable/production quality.
You can read more about X-Accountant at its home page
-
+
http://www.cs.hmc.edu/~rclark/xacc/index.old.html.
The GnuCash pages
@@ -31,8 +31,7 @@ aimed at developers, not users.
The version 1.1.x is *unstable* (may not even compile), and is in
active development. This page attempts to describe the current
-goals & status. Current efforts center around a port to GTK, and
-the addition of various features.
+goals & status.
We believe that a GNU GPL project should provide goals and motivations
at both the large and the small scales, in order to focus and motivate
@@ -41,7 +40,7 @@ and carry out; yet their lack serves only to dissuade the grand
thinkers. A list of detailed goals may be mind-numbing to the casual
reader; yet, without them, the roll-up-your-sleeves-and-do-it
coder cannot know where to begin. Detailed goals lend a concreteness
-to the discussion: they can be architect-ed, designed and coded at any time
+to the discussion: they can be architected, designed and coded at any time
by coders of any ability. Thus, we present a list of goals, large and
small, with the hope that the small goals will fall quickly, and the
large ones shall turn into a multitude of small ones.
@@ -49,6 +48,12 @@ large ones shall turn into a multitude of small ones.
News
+- September 1998
+
- Version 1.1.18 is begining to get stable; most things work the way they're
+ supposed to. New features include variety of ways of viewing an account,
+ a simple query engine, and support for multiplecurrencies.
+
+
- April 1998
- The domain "gnucash.org" has been registered; web site is up.
@@ -77,30 +82,51 @@ large ones shall turn into a multitude of small ones.
Meta-Architecture Goals
-Create a clean separation between the data structures and the
-GUI that manipulates them, along the lines of a "Model-View-Controller"
+
+-
+Create and maintain a clean separation between the data structures and the
+GUI that manipulates them, along the lines of a Model-View-Controller
paradigm. Lists of accounts and the transactions in
them can be thought of as a representation of financial data,
-a "Model". The GUI that adds, modifies and deletes these should
-be thought of as a manipulator of the data, a "Controller".
+a Model. The GUI that adds, modifies and deletes these should
+be thought of as a manipulator of the data, a Controller.
The current Motif GUI is just
one possible manipulator of the data; other GUI's,
some simple, some complex, some possibly based on other graphical
-toolkits (QT, Fresco) should be possible. The "View" of the data
-is the modern way of saying a "report". A report generator
-can create balance sheets and profit&loss statements, it can create pie
-charts of asset allocations, or graphs asset value over time.
+toolkits (Qt, gtk, emacs) should be possible.
+The View of the data is a modern way of saying "report".
+One typically does not view, or want to view all of the data,
+but only a subset: say, only the transactions for the month of May,
+or only the account totals for certain accounts. The concept of "View"
+in fact consists of two very separate ideas: the Query Engine
+and the Report Generator. The Query Engine is used to extract
+a list of transactions from the Model database, based on a set of dates,
+a set of types, or other criteria. This list is then typically
+edited by the controller, or possibly printed. The Report Generator
+is used to create summary reports about average account balances,
+or profit&loss statements, or cash-flow statements, or may be graphed
+as pie charts of asset allocations, or graphs asset value over time.
+
-
Create a mechanism for obtaining data from multiple financial sources.
Currently, GnuCash stores data in its own file format; it can also
import Quicken(TM) QIF files. However, other sources & sinks of data
-might be stock-quote web sites, on-line banking interfaces, or
-access to SQL databases. It should be possible to have any of these at
-as data sources, and with the appropriate security mechanisms, it should
-also be possible to update these.
+might be stock-quote web sites, on-line banking interfaces such as OFX,
+access to SQL databases, such as those of Linux-Kontor, or CORBA interfaces,
+such as the GL Ledger submission to the OMG. It should be possible to have
+any of these at as data sources, and with the appropriate security mechanisms,
+it should also be possible for a user of GnuCash to manipulate the data
+at the other end.
+
+In particular, with respect to OFX & online banking, one should be able to think
+of GnuCash as a very special browser, capable of browsing financial web sites.
+Instead of talking HTML/HTTP, it would talk OFX or Gold with the remote
+server. Besides just statically viewing ones bank account, it should also
+allow bill payment and other account manipulation.
+
-
Create both a personal-financial accounting system, as well as a
business accounting framework. Although these two goals may seem at
odds with each other, there is no reason why they could not share
@@ -119,6 +145,7 @@ a ledger window, and a report generation mechanism. The tools
created to allow one should be portable enough to be deployed in the
other application as well.
+
Concrete Architectural and Development Goals
@@ -145,27 +172,61 @@ architectural goals.
separation would make the design and implementation of new ledger
windows much simpler and easier.
- Current Status: the latest alpha-development releases (version
+ Current Status: the latest beta-development releases (version
1.1.x) contain such an object.
- Currently Motif-based
-
- GTK port is read-only
-
- No Qt port yet
+
- GTK port mostly work, but is hung up on the inadequacies of
+ underlying table widget.
+
- No Qt port yet of the register.
- the simple single-account ledgers (incl. stock ledgers) seem
to be working correctly, but no heavy testing yet.
-
- The multiple-account ledger is ery broken.
-
- The multi-split ledger is still unimplemented. Since I know
- how this should work, I hope to work on it soon.
-
- read-only GTK version published, thanks to Rob Browning.
+
- The multiple-account ledger is very broken.
+
- The multi-split ledger seems to work. One can display
+ one line per transaction, two lines per transaction, one line
+ per split, or a dynamic-expansion version of these.
+
- GTK version published, thanks to Rob Browning.
(other comments above are for motif version).
-
- query for date range completely missing.
-
- No curses version yet.
+
- No curses or emacs version yet.
- Taxes: For handling e.g. new zealand GST tax (12.5%) or british VAT,
it would be enough to add a checkbox to say y/n, add tax ...
(of course other schemes would be more sophisticated.)
+
- Linas Vepstas is handling the "GUI-independent"
+ parts of the register, as well as the Motif code.
+
- Ted Lemon <mellon@hoffman.vix.com>
+ is creating/fixing/extending
+ the underlying gtk widget to have the features that GnuCash needs.
+
- Engine, Financial Objects
+
- The current system makes a distinction between the data (account,
+ transaction) and they GUI that displays it. The data is embeded
+ within and controlled by the "Engine", which is a set of routines
+ to access accounts, transactions, etc. The flexibility and features
+ of the engine can be improved, and in particular, the sophistication of
+ the query generator, and the level of multiple-currency support.
+ But possibly the most important task is to review the paradigm
+ and adjust it to bring it in line with a transaction-processing
+ model.
+
+ Current Status:
+
+ - The basic engine has been detangled from
+ the GUI elements, as of version 1.1.4.
+
- Binary file I/O mostly detangled into a separate module.
+
- Prototype for transaction logging in place
+
- Backup files automatically created & timestamped.
+
- BeginEdit()/CommitEdit() routines mostly in place,
+ These "Transaction processing constructs"
+ should simplify creation of an SQL back end.
+
- Multiple currency support is shaky.
+
- Query engine is minimal/sparse in capabilities.
+
- Linas is handling the engine code.
+
+
+
+
- Extension Language Support
- Currently, the application is wired together entirely with
C code. A goal of the project is to replace this wiring with
@@ -186,11 +247,15 @@ architectural goals.
At the final stages, it is hoped that new modules can be imported
without requiring that the application itself be recompiled & relinked.
- Status: Work has begun. The transaction engine interfaces
- are avaialable via
-
- SWIG.
- A scheme-based user-preferences/configuration file has been created.
+ Status:
+
+ - Work has begun.
+
- The transaction engine interfaces are avaialable via
+
+ SWIG.
+
- The main loop is controlled by the Guile scheme interpreter.
+
- Rob Browning is the reigning expert.
+
- Multi-user Support
@@ -222,30 +287,6 @@ architectural goals.
SQL does NOT require locks to be held for long periods of time!
-
- Engine, Financial Objects
-
- The current system makes a distinction between the data (account,
- transaction) and they GUI that displays it. This distinction should
- be further strengthened, and a set of financial objects, residing in
- their own library, should be created. Routines to help make the
- engine more transaction-processing oriented should be added.
-
- Current Status:
-
- - The basic engine has been detangled from
- the GUI elements, as of version 1.1.4.
-
- Binary file i/o still remains tangled.
-
- prototype for transaction logging in place
-
- backup files automatically created & timestamped.
-
- BeginEdit()/CommitEdit() routines mostly in place,
- These "Transaction processing constructs"
- should simplify creation of an SQL back end.
-
- Engine seems to be working correctly, but no heavy testing yet.
-
- Support for alternate sort orders, or query for subset of
- all transactions completely missing.
-
-
-
-
- OFX support
- Provide the SGML DTD parsers to handle the OFX reports that many
banking institutions are providing, or will soon be providing, to
@@ -258,7 +299,10 @@ architectural goals.
- Work on an OFX DTD parser has begun. headers generated
correctly. Constrcutors generated almost correctly.
+ Parser work done by Linas.
- Simple scripts have been run against real-live OFX servers.
+ Ueli Rutishauser
+ has been able to do e*trade transactions to a real account.
@@ -276,6 +320,18 @@ The following is a list of goals and "bug fixes" that should be solved
immediately, independent of the major goals.
+- User Interface Ports
+
- Port the package as a whole to gtk/gnome, Qt, Emacs
+ Status:
+
+ - Jim Pick <jimpick@jimpick.com> may be working on an emacs version...
+
- Daniel R Risacher <magnus@alum.mit.edu> is taking over the overall
+ gtk/gnome work from Jeremy Collins.
+
- Qt code submitted by ...
+
+
+
+
- Categories
- Provide a default list of "Categories" (Income/Expense Accounts).
These are categories such as "Automobile Expense", "Bank Interest
@@ -292,19 +348,22 @@ immediately, independent of the major goals.
- Internationalization
- All menus, markup and help-text should be internationalized,
- so that X-Accountant could be usable in any country. This
+ so that GnuCash could be usable in any country. This
would include the printing of currency values in the local
country conventions.
- Current status: most English-language messages have been
- #defined and moved to a single header file. (messages.h)
- (Will use gnu gettext for the message catalogues. ??)
- Looking for routines that can parse and print
- monetary values in different formats, as well as date/time
- parsing/printing routines. (xacc contains such parsing
- routines, but they're not very powerful or i18n'ed.)
-
- Henning Spruth has translated the README into German.
+ Current status:
+
+ - Most English-language messages have been
+ #defined and moved to a single header file. (messages.h)
+
- Plan to use gnu gettext() for the message catalogues.
+
- Looking for routines that can parse and print
+ monetary values in different formats, as well as date/time
+ parsing/printing routines. (gnucash contains such parsing
+ routines, but they're not very powerful or i18n'ed.)
+
- Henning Spruth has translated the README into German.
+
-
+
- Recurring Transactions
@@ -314,6 +373,10 @@ immediately, independent of the major goals.
whether the multi-user functions are available or not.
Note also, maybe the engine needs to support two dates per
transaction: expected, and actual ??
+ Current status:
+
+ - Design Doc contributed by Bob Drzyzgula
+
- Navigation
@@ -330,7 +393,7 @@ immediately, independent of the major goals.
- A set of pretty icons and button pixmaps should be created for
minimized windows, and for the various buttons. A user-configurable
button-bar would be nice too. This should probably be coupled with
- the creation of an X resource file, which does not currenyl exist.
+ the creation of an X resource file, which does not currently exist.
- Folder Tabs
@@ -368,6 +431,12 @@ immediately, independent of the major goals.
transaction cannot be completed until two accounts have been specified.
It should also be possible to sweep through the date, and find all
dangling transactions.
+ Current status:
+
+ - The engine has a couple of flags in it that control this;
+ however, they are compiled in, there is no way to change them
+ from the gui.
+
- Transaction Window Fixes
@@ -387,6 +456,11 @@ immediately, independent of the major goals.
- Create menu system & file format for manipulating user
preferences. Preferences include things like showing/not
showing categories, forcing double-entry, etc.
+ Current status:
+
+ - Rob Browning has put together a basic infrastructure
+ that unifies command-line flags with sceme-based config files.
+
- Bonds & Interest Bearing Instruments
@@ -501,11 +575,6 @@ immediately, independent of the major goals.
transactions.)
-
- Variety of Sorting Orders
-
- Sort entries in register by date of key-in rather than date of
- entry, or by date of clearing. Or sort alphabetically. Also,
- filter, i.e. show only those entries of a particular type ...
-
- emacs & vi Key Bindings for Text Fields
- Make sure that text fields can handle the vi & emacs key bindings,
so that e.g. ctrl-a, ctrl-k works.
@@ -565,25 +634,18 @@ Well, just to show that we are getting things done.
Volunteers
Your name here as project contributor!
-- Linas Vepstas is maintaining the current xacc
+
- Linas Vepstas is maintaining the current GnuCash
and is attempting to coordinate the project work.
-
- Jeremy Collins , originator of the GnoMoney
- project, is working on a GTK port.
+
- Jeremy Collins , originated the GnoMoney
+ project, created the intial GTK port, and set up the GnuCash web site.
- Rob Browning (rlb@cs.utexas.edu)
- ex-cbb'er, has begun work on a GTK-based graphing package.
-
- Robin Clark , the *original* X-Accountant author,
- is creating a register widget in QT/KDE
-
- Henning Spruth
- hopes to work in internationalization & locale issues,
- including a translation to German.
-
- Bradley M. Kuhn hopes to coordinate assorted
- activities.
-
- Peter Norton is working on a GTK port of Xbae
+ ex-cbb'er, has ported the register to gtk, built a generic preferences
+ infrastructure, got the extension language pieces to work.
+ and has done some work on a GTK-based graphing package.
+
- Robin Clark wrote the *original* X-Accountant,
+ which was later renamed as GnuCash.
- Daniel R Risacher is working on a
GTK ledger/register/spread-sheet infrastructure.
-
- Michael Newlyn Blake hopes to putter
- around with QIF export.
-
- Brian Cooper GTK port of interface.
This list only mentions the currently active developers; many, many others
have contributed fixes and patches. I've tried to credit them in the README.
@@ -646,8 +708,7 @@ cvs -d :pserver:anonymous@im2.lcs.mit.edu:/im/magnus/cvsroot get watermark
-Draft version 0.22 -- April 1998
+Draft version 0.23 -- September 1998
Linas Vepstas linas@linas.org
-Robin Clark rclark@hmc.edu