GnuCash design / new features

[Neil Williams]

On Sunday 30 October 2005 2:44 am, Brian Rose wrote:
> Hmm, I was hoping it would be possible to use
> Gnucash via the desktop for one user
> and via a webpage for another user
> simultaneously--maybe that is a longer way off than
> I thought.

None of the current developers have shown an inclination to work on such a 
feature so it will remain a long way off until someone decides it is worth 
investigating. It is a lot more complex than you may envisage - mainly 
because of the implicit logic that is hard to replicate in a browser 
environment. You'd need something compiled on the server that could do the 
job, maybe a new perl module that wraps a new C library or the proposed logic 
library required for cashutil.

> Well, the site explains the theory pretty well.
> However, I am throwing out ideas for
> consideration to make Gnucash "tasty" to an
> enduser/small business owner who isn't
> a Linux guy--e.g., avoids the command-line and
> doesn't want to code.

I suggest you look at QSF and maybe help me finish off the conversion routines 
and invoice export.

> Well, for one it would be really awesome if the
> invoice template was similar to iBiz,
> http://www.iggsoftware.com/ibiz/index.html .

1. We don't want to have specific external targets from within gnucash like 
that - the reference you quote is a moving target and if we try to "fix" 
against it, it will always be a case of catch-up.

2. Someone else will undoubtedly have yet another target that should be 
considered.

3. QSF *can* deal with ANY external customisation requests. By having just the 
data required, you can develop a simple Perl/Python/PHP/whatever process that 
parses the XML and produces the template / report / format you need for 
whatever your target may be. It's designed to be all things to all men and 
once a conversion script is created, it remains current because all that is 
changing is the internal data - not the QSF format itself.

> Highly flexible, but using a GUI and a template
> creator.

If it's flexible enough to import data into that template, QSF can provide the 
data. It's just a question of a suitable script to process the output.

> > Are you happier in GUI development or CLI or both?
>
> Web dev and backend stuff is where I am most
> comfortable.

Sounds perfect. Backend stuff will be the invoice QSF which still needs a few 
tweaks in src/business/business-core/gncInvoice.c and 
src/backend/qsf/qsf-backend.c - contact me off-list if you'd like to look 
into that and I can send you some examples.

Web dev stuff is really down to your preference of Perl, PHP, Python, XQuery, 
XPath or something else to parse the XML and output the data in a format 
suitable for your template.

> Well, I am not sure other than above on invoices
> and what others have mentioned in
> this thread.

Fine, that's enough for now. It's how I started too.

> My primary purpose is speaking up is because I
> want to help enable more productivity
> and more small business users and hence a better,
> stronger Gnucash.

In which case, you will be very welcome here.

> Derek mentioned that there were enough web
> programmers. Is there a need for people
> to port documentation from the dev list and
> doxygen to the web to help enable new
> programmers with Gnucash to be productive more
> quickly?

Yes - the only question is WHERE that documentation should be hosted. I've had 
to host my own (http://code.neil.williamsleesmill.me.uk/) because access to 
the gnucash site is so limited. I do have space there to host some more but 
I'd have to arrange some form of access until I get time to put Drupal onto 
that box.

What I think we need is:

1. Entry-level docs that fill the gap between the detailed doxygen output, the 
patchy "related pages" docs - some of which are quite outdated - and the 
current gnucash website.

2. Tips and advice on how to manage the gnucash codebase. The tools to use and 
links to their documentation. Conventions and when to use branches.

3. A concerted effort to bring the existing disparate docs into one cohesive 
whole that is relevant, friendly, welcoming, genuinely helpful and bridges 
the gap between the gnucash-docs package and the gnucash-devel archives.

4. Regular and consistent updates to all documentation components.

Realistically, this can only be achieved by using a tool that provides write 
access to all developers with CVS/SVN commit rights plus a few others with 
documentation skills - i.e. some form of CMS. I'd recommend Drupal.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20051030/2f9e529f/attachment.bin