Request for comment: GnuPOS - A Point-Of-Sale program

[Conrad Canterford]

All,
I have started development of a point-of-sale program. I'll spare you
the long story, but suffice to say that I've used QuickPOS (the
point-of-sale offering from Intuit/Quicken) and its got holes you can
drive trucks through. Having been inspired by Gnucash, I decided the
best solution was to write a GPL'd equivalent.

WHAT I WANT
Well, everything, really. In unordered point-form:
- interface to gnucash ('cos that is where my accounts are).
- stand-alone capability (just in case some strange people don't want to
run gnucash).
- configurable gui ('cos not everyone wants things looking the same).
- programmable keymap/other input structure (so it can be used in a
whole stack of different industries).
- stock-control/inventory stuff. 
- multi-user/multi-instance operability with *SECURITY* a high priority
- no doubt many more things that just don't come to mind at the moment.

WHAT I'VE DONE SO FAR
This is open to comments - I want feedback before I progress too far to
make changing practical.
- The gui exists in rather unpolished form. The layout look remarkably
similar to the QuickPOS layout. I'll post the glade file later for
people to look at. Essentially, it consists of a long, narrow text box
at the top to contain the "current input". The rest of the window below
that is divided into two panes, the left to contain on ongoing log
similar to the paper cash-register rolls the average cash register
produces (this should probably also log to a file). The right-side pane
is intended as a help/prompt/message window. The stuff output to either
will be programmable.
- Most of the functionality to resize works mostly ok for what I've
done, but it needs cleaning up. There are no doubt other options I've
not considered that could be added.
- I have writen some basic functions for displaying stuff in the gui,
but it was primallily intended for testing purposes, and will no doubt
need to be extended. In particular, I'm eagerly awaiting GTK+ 2.0, which
has some much nicer text display widgets that I'd like for the right
pane in particular.
- After a (miniscule) amount of discussion on irc and with friends, I
have decided an xml-format file is the go for keyboard programming,
using a state machine setup. I'm not sure how to explain this, so just
throw ideas at me, and I'll add/change stuff that seems interesting. It
is my intention that *all* operation go through the state machine (in
other words, I want no "automatic" things that happen - everything
should happen or not happen according to the programming).
- I have writen the preliminary stuff for reading the xml file and
building the state tables. This is very preliminary, but is what I'm
currently working on, so it will probably grow fairly quickly. Again, I
can't realy explain what I mean, so I'll see if I can make the stuff
available somewhere.
- I have a fairly good idea how these tables will work in interpreting
keystrokes. If this idea survives discussion and/or implementation is
another matter. It mostly consists of a number of arrays containing the
necessary data as fed in on the reading of the xml file. It is my hope
that this will be quick without being too much of a memory hog, but this
may have to be revisited again in the future once some experience is
gained. Feel free to throw suggestions at me. 
- It is my intention (once I get that far) to have all numerical values
treated as gnc-numerics. One of my really huge gripes about QuickPOS is
that it uses low-bitcount floats for price representations, leading to
rounding errors in some cases for multiples as low as 2. This is
completely avoidable and utterly wrong in my opinion, so mine will not
do that.

OTHER ISSUES
Not much to add here at the moment, except that:
- ultimately, some way is going to have to be found to encrypt the data.
Of course, we don't have any data that really needs encrypting just at
the moment (I don't think encrypting the keyboard program xml file is
really necessary). This is a multi-user issue (and potentially an issue
when inventory stuff is added).

I'll update this as I go along, but don't expect it to be immensely
current!

Conrad.
- 
-- 
Conrad Canterford  (conrad@mail.watersprite.com.au)
Water Sprite Pty Ltd   |  Watersprite Pty Ltd:
GPO Box 355,           |  - Australian Tour and Event Management (ATEM)
Canberra, ACT 2601     |  - Ticketing Division.
Mobile: +61 402 697054 |  - Catering Services Division.