From e529d35d33f4b601da9610727d7dd2cf24e54b8c Mon Sep 17 00:00:00 2001 From: Linas Vepstas Date: Tue, 29 Sep 1998 02:05:38 +0000 Subject: [PATCH] updates git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@1233 57a11ea4-9604-0410-9ed3-97b8803252fd --- Docs/projects.html | 237 ++++++++++++++++++++++++++++----------------- 1 file changed, 149 insertions(+), 88 deletions(-) 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