Re: GnuCash design / new features

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Neil Williams-2
On Friday 28 October 2005 4:58 am, Brian Rose wrote:

(switched to devel)

> And budget support.

Chris Shoemaker has been working on this, it's just been added to G2.

> Also, what would happen if the engine and
> functionality was separated from the GUI?

I'm working on that. QOF is the GnuCash engine without the financial objects
and that has been spun out of GnuCash.
http://qof.sourceforge.net/

The financial functionality is being separated from the GUI too - the objects
(Accounts, Invoices etc.) are to be shared with cashutil:
http://linux.codehelp.co.uk/cashutil/

What needs to follow is the financial logic - only part of which is currently
embodied in the objects. CashUtil will be folded into the gnucash sources but
ONLY after the Gnome2 port is released.

> Then provide good docs and an api for building a
> frontend using a web page, KDE, Gnome2,
> OS X,

1. OSX already has GnuCash via X11 and Fink (there could be licence problems
with a native Cocoa port and it is not being considered).
2. KDE can run GnuCash if the Gnome libraries are installed. KDE also has it's
own alternatives to GnuCash.
3. The web page idea is FAR more difficult than you may imagine and NONE of
the work above even comes close to a HTML/PHP/Perl front end. I've done work
on QSF (XML) which *could* be used to render GnuCash (and other QOF) data as
HTML for purposes of data mining and customised reports but that's definitely
as far as it goes.

> ... Secondly why not provide similar support
> for extensions like Mozilla has, that can
> be easily installed by the user?

1. GnuCash 1.8 has it's own module system because the Gnome1 libraries didn't
do what was needed. Gnome2 libraries (in particular GModule) can but this
work has only been done so far for the backends. Plugins for backends are
part of my plan for QOF and therefore GnuCash.
2. Mozilla designed for plugins from the very earliest stages, it's not easy
to build a system into an existing program.
3. Plugins can only go so far and still won't meet everyone's needs. IMHO, it
is better to provide easier, more robust access to the data itself and let
users handle it in Perl or PHP, Python or whatever. QSF is a flavour of XML
that has a Schema and is intended to provide this simple and flexible data
access.

http://www.data-freedom.org/

> I would be more
> open to reading docs and using an
> API to "scratch my itches", compared to
> downloading the gnucash source and studying it
> for a while to know how my first attempt at a
> module is going to affect everything else
> before I can contribute.

What functionality do you want in your module?

> It seems very daunting
> and time consuming.

There's no escaping that one. Developing in gnucash could quite easily consume
150% of your available time. The discipline to control that must come from
you, as must the motivation to persist.

> I have been reading
> the devel lists for a week now and threads gone
> and on and on. Is there a "benevolent
> dictator/leader" or a specific milestone map or
> are the developers just doing what seems
> best to each of themselves?

The "map" at the moment is G2. Discussions are ranging over tools and
philosophies but that is all about the future. There has been a long standing
need to move away from CVS but it cannot start until G2 is sorted out.
However, the discussions upon what to use instead and how gnucash development
should be organised after G2 have provoked marked differences of opinion
between the current group of active developers.

As for "each to his own", there was angst about my work on QOF but despite all
the problems that is now done. I am not a GUI programmer, never have been. I
work on gnucash because I want to provide easier access to gnucash data, not
because I had any designs for a whizzo GUI frontend or even new GUI
components. Others are already far better at that than I will ever be.

So I guess it depends on your motivation, your perspective and your "itch". I
work with command-line interfaces (like cashutil) because I dislike the
"bloat" of GUI programming. I have a need for better data access from various
devices and situations so I concentrate on QOF, backends, CLI programs and
XML. If you want a quick introduction to the fundamentals of gnucash, you
could do worse than look at the cashutil code which is currently a very
stripped-down CLI version of gnucash. There is a lot more work needing to be
done on cashutil. We each need our own "itch" for motivation.

Are you happier in GUI development or CLI or both?

What's your itch?

--

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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Josh Sled
On Fri, 2005-10-28 at 22:06 +0100, Neil Williams wrote:
> On Friday 28 October 2005 4:58 am, Brian Rose wrote:
>
> (switched to devel)

>From where?  Where can I see the original message?

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Brian-5
On Fri, 2005-28-10 at 18:00 -0400, Josh Sled wrote:
> On Fri, 2005-10-28 at 22:06 +0100, Neil Williams wrote:
> > On Friday 28 October 2005 4:58 am, Brian Rose wrote:
> >
> > (switched to devel)
>
> >From where?  Where can I see the original message?
>
> ...jsled

It's in gnucash-user

Here's his post:


>>>From months of list reading these are things that concern list users
>>1. End of financial year close issues
>>2. Invoice printing including font choice and Fancy invoice
customisation
>>3. Connecting with PalmOS
>>4. Choosing a customer or vendor when doing invoices or payments is
clumsy
>>5. Cheque printing
>>6. Multi-user version
>
>
> I would have to add to this list "Recurring invoices."...

And budget support.
Also, what would happen if the engine and
functionality was separated from the GUI?
Then provide good docs and an api for building a
frontend using a web page, KDE, Gnome2,
OS X, ... Secondly why not provide similar support
for extensions like Mozilla has, that can
be easily installed by the user? I would be more
open to reading docs and using an
API to "scratch my itches", compared to
downloading the gnucash source and studying it
for a while to know how my first attempt at a
module is going to affect everything else
before I can contribute. It seems very daunting
and time consuming. I have been reading
the devel lists for a week now and threads gone
and on and on. Is there a "benevolent
dictator/leader" or a specific milestone map or
are the developers just doing what seems
best to each of themselves?

Sincerely,
Brian
--
Contagious Design!
web . design . photo

Brian Rose .  web programmer
(604)-630-2426 . brianATcontagiousdesignDOTnet

--
Brian <[hidden email]>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Brian Rose-2
In reply to this post by Neil Williams-2
Hi all,

>
> 1. OSX already has GnuCash via X11 and Fink (there could be licence problems
> with a native Cocoa port and it is not being considered).

Ok.
> 2. KDE can run GnuCash if the Gnome libraries are installed. KDE also has it's
> own alternatives to GnuCash.

Just a thought.

> 3. The web page idea is FAR more difficult than you may imagine and NONE of
> the work above even comes close to a HTML/PHP/Perl front end. I've done work
> on QSF (XML) which *could* be used to render GnuCash (and other QOF) data as
> HTML for purposes of data mining and customised reports but that's definitely
> as far as it goes.

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.

> 2. Mozilla designed for plugins from the very earliest stages, it's not easy
> to build a system into an existing program.

True.

> 3. Plugins can only go so far and still won't meet everyone's needs. IMHO, it
> is better to provide easier, more robust access to the data itself and let
> users handle it in Perl or PHP, Python or whatever. QSF is a flavour of XML
> that has a Schema and is intended to provide this simple and flexible data
> access.
>


> http://www.data-freedom.org/

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.

> What functionality do you want in your module?

Well, for one it would be really awesome if the
invoice template was similar to iBiz,
http://www.iggsoftware.com/ibiz/index.html . My
wife uses iBiz. I don't like a lot of it--(it
is to click-happy for me), however the invoice
template creator is pretty good. It uses a
"web template" like method of specifying where
everything goes for an invoice template.
Highly flexible, but using a GUI and a template
creator.


>
>>It seems very daunting
>>and time consuming.
>
>
> There's no escaping that one. Developing in gnucash could quite easily consume
> 150% of your available time. The discipline to control that must come from
> you, as must the motivation to persist.
>
>
Most any project is similar that way, isn't it?

> So I guess it depends on your motivation, your perspective and your "itch".
...
  We each need our own "itch" for motivation.
>
> Are you happier in GUI development or CLI or both?
>
Web dev and backend stuff is where I am most
comfortable.

> What's your itch?
>
Well, I am not sure other than above on invoices
and what others have mentioned in
this thread.

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.

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?

Sincerely,
Brian

--
Contagious Design!
web . design . photo

Brian Rose .  web programmer
(604)-630-2426 . brianATcontagiousdesignDOTnet

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Neil Williams-2
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/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Derek Atkins
Quoting Neil Williams <[hidden email]>:

>> 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.

The only reason you've had to do that is because I've only run the
doxygen docs on HEAD, not g2.  Once g2->HEAD then you'll no longer need
to do that for doxygen.

-derek
--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Neil Williams-2
On Sunday 30 October 2005 1:24 pm, Derek Atkins wrote:

> Quoting Neil Williams <[hidden email]>:
> >> 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.
>
> The only reason you've had to do that is because I've only run the
> doxygen docs on HEAD, not g2.  Once g2->HEAD then you'll no longer need
> to do that for doxygen.
True, however I was thinking of my other documentation on that server. The URL
itself goes to the DocBook documentation I wrote for qof_book_merge and QSF
rather than the G2 Doxygen output.


--

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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Derek Atkins
Quoting Neil Williams <[hidden email]>:

> True, however I was thinking of my other documentation on that
> server. The URL
> itself goes to the DocBook documentation I wrote for qof_book_merge and QSF
> rather than the G2 Doxygen output.

Just a side question...  is there any particular reason the qof_book_merge
docs aren't in doxygen?  I can somewhat understand why QSF docs aren't.

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Neil Williams-2
On Sunday 30 October 2005 3:18 pm, Derek Atkins wrote:
> Quoting Neil Williams <[hidden email]>:
> > True, however I was thinking of my other documentation on that
> > server. The URL
> > itself goes to the DocBook documentation I wrote for qof_book_merge and
> > QSF rather than the G2 Doxygen output.
>
> Just a side question...  is there any particular reason the qof_book_merge
> docs aren't in doxygen?  I can somewhat understand why QSF docs aren't.

The qof_book_merge API is in Doxygen - lots and lots of it. The stuff on my
own server is more the design behind the API along with links to a whole
range of other documentation. I suppose it's grown beyond the
"qof_book_merge" name really but I have now subtitled it:
"Query Object Framework: Design and direction." to give a hint that it's more
than just the merge.
http://code.neil.williamsleesmill.me.uk/

The index (including some pages that just link to other sites or documentation
generated from other projects) covers:
Preface
1. QOF dependencies.
2. GnuCash dependencies.
2.1. GnuCash for Gnome2: gnucash-gnome2-dev
2.2. Building GnuCash
1. Introduction
1.1. Terms and definitions.
1.1.1. QOF: Query Object Framework .
1.1.2. Pilot-QOF: Querying Palm databases as objects.
1.1.3. QOF-gen: QOF Object Generator.
1.1.4. Data Freedom: Liberate your data from the application.
1.1.5. What's a QofBook?
1.1.6. QSF - QOF Serialization Format.
1.2. Other versions of this documentation.
2. Background
3. Source Documentation
3.1. Doxygen Documentation.
3.1.1. qof_book_merge Doxygen documentation.
3.1.2. QSF Doxygen documentation.
3.1.3. QOF Doxygen documentation.
3.1.4. GnuCash Doxygen documentation.
3.1.5. GnuCash Gnome2 port Doxygen documentation.
3.2. Other general documentation
3.2.1. Gnucash Design documentation
3.2.2. GnuCash Tutorial and Concepts Guide
3.2.3. GnuCash Help Manual
3.2.4. KVP Values used By GnuCash
3.3. qof_book_merge Source Code
3.4. QSF Source code
3.4.1. QSF and qof_book_merge tarballs
4. Creating GnuCash Invoices using a Palm PDA
4.1. Beginnings
4.2. Getting into GnuCash / QOF
4.2.1. Why the GnuCash File QofBackend needs changing
4.2.2. Tips on debugging within GnuCash
4.3. Building QOF onto pilot-link
4.3.1. Converting existing objects to QOF
4.4. Pilot-QOF
4.4.1. What does QOF have to do with pilot-link, or vice versa?
4.4.2. pilot-qof manpages
4.4.3. Generating new objects
5. QSF - QOF Serialization Format.
5.1. What is QSF?
5.1.1. Features of QSF
5.1.2. Requirements of QSF
5.1.3. Validation of QSF.
5.1.4. QSF examples
5.2. Mapping QSF objects between QOF applications
5.2.1. The QSF Map file
5.2.2. Relating the map to the QSF objects
5.3. Writing new QSF maps
6. Merging QofBook's
6.1. Preparing the rule set
6.2. Draft of a rule set framework.
6.3. Design of the merge
6.3.1. Example programs for qof_book_merge
6.4. Using qof_book_merge with new and existing QOF objects
6.5. Known problems
6.6. Design improvements
7. Data Mining and freedom of access.
7.1. Data mining within QOF
7.2. Data Freedom within QOF

I think I've got the split about right - maybe there is still too much in the
Doxygen output but there are topics covered at my own site that simply don't
fit into gnucash or QOF doxygen.

--

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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Josh Sled
In reply to this post by Neil Williams-2
On Sun, 2005-10-30 at 09:53 +0000, Neil Williams wrote:
> 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

Actually, you and warlord have both said this recently, and I just
wanted to say that I *do* want to do this, actually.  But it's
sufficiently far enough out on my todo list (1 year, at least) as to
practically be useless. :)

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Brian Rose-2
In reply to this post by Neil Williams-2
Hi,

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

>
>>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.
>
I wasn't suggesting mimicking iBiz.

> 2. Someone else will undoubtedly have yet another target that should be
> considered.
Probably. Maybe we could come up with something to
enable customizing invoices
without leaving the Gnucash GUI and iBiz applies
one way. So, several suggestions could
be incorporated to create something better than
the wisdom of anyone person.

>
> 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.
>
Sounds very high-level, generalized, and vague.
I.e., I don't understand, but maybe I will
after reading about QSF.

>
>>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.
>
Who is expected to write the script? Who is
Gnucash intended for?

>
>>>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.

I will read about QSF.

>
> 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.

Sounds good, but what do you think, Derek, about
2,3, and 4--directly above?

Sincerely,
Brian

--
Contagious Design!
web . design . photo

Brian Rose .  web programmer
(604)-630-2426 . brianATcontagiousdesignDOTnet

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Derek Atkins
Quoting Brian Rose <[hidden email]>:

>>> 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.
>>
> I wasn't suggesting mimicking iBiz.

Another option we've discussed previously is e-guile..  This would make
invoice templates effectively hand-written HTML with embedded guile..
So if you wanted to change the look at feel of your invoice you would
just edit the HTML until it looked how you wanted it to look..  And then
the embedded guile interpreter would run the template you created
and display it with the relevant information.

Then we could also distribute a bunch of templates (similar to iBiz)
and you could choose one or create your own.

Unfortunately as I was looking for an e-guile link I noticed that the
author restructured his website and the old page is no longer there.
I just emailed him about it.  As I recall e-guile was effectively a single
source file, so we could just copy-and-paste it into GnuCash and then
someone would just need to figure out how to integrate it into the
report subsystem and set up a runtime environment for a report template.

>> 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.
>
> Sounds good, but what do you think, Derek, about 2,3, and 4--directly above?

I think they sound like a great idea.  I would love for someone to dedicate
time to coalescing all the various docs, finding out what docs are missing,
what docs are duplicated, and honing down our docs into:

  user-docs  (gnucash-docs package)
  dev-docs   (in doxygen)
  build docs (README, HACKING, ...)
  arch docs  (everything else, which bridges the gaps)

I don't believe we'd need something like Drupal for this; I think this
could all be done in CVS/SVN.

> Sincerely,
> Brian

-derek
--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Brian Rose-2

>
> Another option we've discussed previously is e-guile..  This would make
> invoice templates effectively hand-written HTML with embedded guile..
> So if you wanted to change the look at feel of your invoice you would
> just edit the HTML until it looked how you wanted it to look..  And then
> the embedded guile interpreter would run the template you created
> and display it with the relevant information.
>
> Then we could also distribute a bunch of templates (similar to iBiz)
> and you could choose one or create your own.

I like this idea.
>
> Unfortunately as I was looking for an e-guile link I noticed that the
> author restructured his website and the old page is no longer there.
> I just emailed him about it.  As I recall e-guile was effectively a single
> source file, so we could just copy-and-paste it into GnuCash and then
> someone would just need to figure out how to integrate it into the
> report subsystem and set up a runtime environment for a report template.
>
Once we have access to that source I would like to
look into it.

>> Sounds good, but what do you think, Derek, about 2,3, and 4--directly
>> above?
>
>
> I think they sound like a great idea.  I would love for someone to dedicate
> time to coalescing all the various docs, finding out what docs are missing,
> what docs are duplicated, and honing down our docs into:
>
>  user-docs  (gnucash-docs package)
>  dev-docs   (in doxygen)
>  build docs (README, HACKING, ...)
>  arch docs  (everything else, which bridges the gaps)
>
> I don't believe we'd need something like Drupal for this; I think this
> could all be done in CVS/SVN.
>

Hmmm, but is there anywhere that says in stuff
like in version 2.5 we will have whatever,
and in v. 3.0 will be these features as well. A
current roadmap I guess. Is it not neccessary to
have all this and the docs above on the/a website?
Right now there is the wiki, gnucash.org,
and then independent developers' sites all with
different info. I want to sound rude, just that
I was confused at where Gnucash is going after G2,
so I thought if I am confused maybe
others are as well--hence the website suggestions.
For example, I read the QSF part on
Neil's site and now I wonder what QOF/QSF has to
do with G2, SQL backend, multi-user
support, .... I am sorry and maybe I am a bit
green on developing such an app, but I just
don't get any of the stuff with QOF/QSF. Is it
part of the "Free the data" concept or to
support multiple backends/platforms or what?

Sincerely,
Brian


--
Contagious Design!
web . design . photo

Brian Rose .  web programmer
(604)-630-2426 . brianATcontagiousdesignDOTnet

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Josh Sled
On Mon, 2005-10-31 at 06:59 -0800, Brian Rose wrote:

> Hmmm, but is there anywhere that says in stuff
> like in version 2.5 we will have whatever,
> and in v. 3.0 will be these features as well. A
> current roadmap I guess. Is it not neccessary to
> have all this and the docs above on the/a website?
> Right now there is the wiki, gnucash.org,
> and then independent developers' sites all with
> different info. I want to sound rude, just that
> I was confused at where Gnucash is going after G2,
> so I thought if I am confused maybe
> others are as well--hence the website suggestions.

This is a good point (except for the wanting to sound rude part ;).

We've been really focused on the G2 port and 2.0, and intentionally
haven't talked with too much rigor about post-2.0, at the same time
there's been a lot of discussion over the last year or so, and I think
it breaks out like:

- General simplification
  - Report <handwave>cleanup</handwave>
  - Scheme removal
  - Finalize QOF extraction
  - Fix modularity system
- Features
  - DB-backend/SQLite integration.
  - Budgeting
  - Book closing
  - Lots
  - SX using QOF (to support above)
  - Register rewrite in "simple" widgets.


It might be possible to plan these out into specific releases/timeframes
if we had regular releases and more than really-part-time developers.
Right now, it's hard to have a realistic roadmap that's more formal.

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design / new features

Brian Rose-2
Oh, no!
>>different info. I want to sound rude, just that
I DO NOT want to sound rude! Yikes! Sorry!
>
> This is a good point (except for the wanting to sound rude part ;).
>
yeah. Well, people really do judge a book by its
cover and a project by its
interface and its website-E.g., "Does it have lots
of cool original eye candy that looks
fairly new, ...." So, if we want to attract more
users, developers, etc--this is why I like
Firefox. Looks great, but is a good product too.

> it breaks out like:
>
> - General simplification
>   - Report <handwave>cleanup</handwave>
>   - Scheme removal
>   - Finalize QOF extraction
>   - Fix modularity system
> - Features
>   - DB-backend/SQLite integration.
>   - Budgeting
>   - Book closing
>   - Lots
>   - SX using QOF (to support above)
>   - Register rewrite in "simple" widgets.
>
Ok.
Sincerely,
Brian

--
Contagious Design!
web . design . photo

Brian Rose .  web programmer
(604)-630-2426 . brianATcontagiousdesignDOTnet

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GnuCash design - the role of QOF and QSF

Neil Williams-2
In reply to this post by Brian Rose-2
On Monday 31 October 2005 2:59 pm, Brian Rose wrote:

> Right now there is the wiki, gnucash.org,
> and then independent developers' sites all with
> different info. I want to sound rude, just that
> I was confused at where Gnucash is going after G2,
> so I thought if I am confused maybe
> others are as well--hence the website suggestions.
> For example, I read the QSF part on
> Neil's site and now I wonder what QOF/QSF has to
> do with G2, SQL backend, multi-user
> support, ....
QOF is a separate library now with it's own development path that will retain
gnucash as a client - incorporating feature requests from gnucash alongside
requests from other client programs and architectures. Other applications
using QOF include GnoTime, Pilot-QOF and cashutil.

QOF and QSF have important benefits for GnuCash and, yes, it is all linked to
data freedom.

QOF is to include full SQL backend support via libgda and the gnome-db
plugins. This will mean that gnucash will inherit generic backend support via
QOF for nearly all the databases you can name - SQLite, MySQL, Postgres,
Oracle, Sybase, ODBC,  FireBird/Interbase, IBM DB2, mSQL and MS
SQL server, as well as MS Access and xBase files. Data in any of these sources
can be shared with any other backend and with any QOF client. (QOF is likely
to move to beta once this is done).

QOF is also going to be built for embedded systems and already has a client
application to work with Palm OS devices. On larger embedded systems, QOF can
run on the mobile device and provide query support on the move - many PDA
utilities lack the ability to use data from other programs on the same device
and native QOF can solve this problem.

The idea is that the user data should be as free as the source code that
creates it. Beating vendor/application lock-in not by reverse engineering but
by making lock-in itself increasingly redundant. Revealing the true colours
of lock-in - the selfish obsession of proprietary developers.

This means that GnuCash G2 gains access to data from a rapidly increasing
range of sources making it far easier to work with your GnuCash data in other
applications and to create GnuCash data from other tools - like a PDA -
without losing the ability to bring the data back into gnucash later on.

Lots of people enter business data like expenses onto a mobile device of some
kind. QOF - as a fundamental component of gnucash - can provide low-level
generic access to all these pieces of data making data entry automation more
available.

QOF will be able to go onto platforms that could never support gnucash and yet
provide gnucash with access to the available data on that platform. Indeed,
each and every QOF client will inherit the same levels of access to each
other QOF client and each QOF backend, on whichever platform QOF is
available.

Pilot-QOF wraps QOF around code from pilot-link to provide a QOF interface for
all devices supported by pilot-link using QSF XML. The same can be done for
other applications - wrapping QOF around existing code to create a new QOF
client that can share data with any other QOF client using any available QOF
backend.

> I am sorry and maybe I am a bit
> green on developing such an app, but I just
> don't get any of the stuff with QOF/QSF. Is it
> part of the "Free the data" concept or to
> support multiple backends/platforms or what?

Both and all.

1. QOF provides simple methods to only export the gnucash data relevant to a
specific query.

2. QOF retains the integrity of that data so that it can be reimported into
gnucash and updated from gnucash.

3. QOF stores this data in whichever backend is chosen - QSF is the default
backend and will be the only backend guaranteed to be available for ALL QOF
clients.

4. QSF is a generic and validated XML that can support detailed and recursive
SQL-type queries for data mining and data extraction / reporting. Any gnucash
data can be made available to a Perl/PHP/Python/whatever script and passed to
any number of customised scripts to provide an infinite number of reports and
analyses.

5. QOF provides the data interchange that allows disparate data sources to
exchange data without loss of data integrity.

This is mostly in the future - but I believe it all to be attainable.

--

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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment