Re: gnucash 2.2.2 segfaults on lenny

[Josh Sled]

Rainer Dorsch [EMAIL PROTECTED] writes:
 I compiled gnucash on a Debian lenny system and already at startup it 
 segfaults. I append a backtrace. 

 Any idea what could be wrong is welcome .

http://svn.gnucash.org/trac/changeset/16766

If you've built it yourself, you can apply the equivalent of that change, or
wait for 2.2.3

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpmAUNF0HO74.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash doesn't load data file

[Josh Sled]

Family [EMAIL PROTECTED] writes:
 Have used gnucash for many years - even donated the loan s/w to the effort.


 Computer died unexpectedly on Wed last. I had made a habit of saving all 
 financial information to 2 separate USB drives and so thought I was home 
 free. 2 separate copies of all information!!!

 It would appear that I was terribly wrong.

 I had been using FC 5

 The new computer is using Kubuntu 7.10 with  gnucash 2.2.x (not sure of 
 last digit.) - do not know previous version of gnucash - whatever is 
 current under FC 5 I think.

 Copied all of the financial directories from a USB drive to the new hard 
 drive. Set up the home directory for gnucash and booted gnucash.

 Went through the business of creating a new account, then canceled that 
 and instructed to open an existing account file. Everything was okay 
 until I attempted to open the old data file.

 Nothing happens.

 gnucash just hangs.

 Thought maybe it was taking a Looong time to read the file.

 Let it run for about 10 minutes - no change. The gnucash window is just 
 vacant and the running icon just goes like the energizer bunny - never 
 stops. Finally clicked the  terminate symbol in the upper right corner - 
 nothing. gnucash is truly hung. Finally KDE informs me that gnucash is 
 not rtesponding and lets me terminate.

 Repeated the above sereval times, even after refreshing the data file 
 from the USB drive each time and deleteing the lock file, etc.

 I have several years of data locked up in that old data file, including 
 the current financial status.

 Is it truly lost?

 Do I really have to start from scratch and count the old information as 
 lost?

 That will lose a lot of information that cannot be regained.

 Tell me that the gnucash devlopers have a solution - please.

 Thanks for any help.

What are the datafile(s) that you copied?

Do you recall what the files/directories they were originally?

What's the path/name of the datafile you're opening?


If you run gnucash from a terminal like such:

$ gnucash --debug --logto stderr

What – if anything – is printed when you open the old datafile and it hangs?

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpZh98WUbz2R.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SLR broken in r16754

[Josh Sled]

Tim Wunder [EMAIL PROTECTED] writes:
 The SX SLR seems to be borken in 2.2.99/r16754. I changed my payday Reminder 
 to a To-Create, clicked OK, but my checking account didn't get updated. The 
 SLR dialog when next run thinks the SX was created, though. Also, if I test 
 this and check the review created transactions checkbox, I'm not shown 
 anything to review.

I'd be curious to see if this is resolved by r16766...?

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpMFtScWdor2.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: progress bar during launching

[Josh Sled]

Herbert Thoma [EMAIL PROTECTED] writes:
 this bothered me as well, not so much because of file loading
 but because of reports.

 I created Bug #506714
 http://bugzilla.gnome.org/show_bug.cgi?id=506714
 and attached a patch that adds a progress bar to the
 splash screen.

 Please review. If OK, please backport to stable.

I've commited this with some modification as r16779.   In particular, your
whitespace didn't match existing conventions.  I also pulled the magic 101
value out into a #define GNC_SPLASH_PERCENTAGE_UNKNOWN in gnc-splash.h.  It's
marked for backport.  Thanks! :)

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpslFTSGUS9U.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Windows Download [WAS: Re: none]

[Josh Sled]

Mike Wardle [EMAIL PROTECTED] writes:
 I saw your free accounting software in the National Association of Realtors 
 magazine, but I am confused on what to download.  I am running Windows XP 
 Professional.  Can you giver directions on what I download.

The first link in the Download section in the navigation on
http://www.gnucash.org/ says […] Windows Binary, and links to
http://sourceforge.net/project/showfiles.php?group_id=192.

(This isn't a development question at all; please use the gnucash-user list
for any similar questions or followup.)

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpUhVqUSJa9P.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Introducing myself

[Josh Sled]

Mike Alexander [EMAIL PROTECTED] writes:
 --On January 5, 2008 3:46:41 PM + mark carter 
 [EMAIL PROTECTED] wrote:

 What exactly is the deal as regards GnuCash using guile 1.6 versus
 1.8.  Would we be expecting to throw up many incompatibilities?

 I've been running Gnucash (SVN revision 16747) with Guile 1.8 for a 
 week or two and it seems to work ok.  I had trouble at first, but it 
 turned out to be a problem with the Macports port of Guile 1.8 which 
 was applying a patch that was no longer relevant to that version.

I believe most distros have gnucash depend against guile-1.8, at this point.
I can't think of a recent example I've seen where it's been mentioned
guile-1.6 is in play.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgp5XkEZg1Jri.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: request for comments on inventory experiment

[Josh Sled]

Lianto Ruyang [EMAIL PROTECTED] writes:
 I hope my description is quite clear and understandable. I need inputs from
 all of you whether this idea is good enough for an inventory system in
 gnucash and can be developed for future needs, any ideas, any directions
 will be greatly appreciated.

I know hardly anything about the practical concept and requirements of
Inventory tracking.

However, the system you proposed sounded very similar to Commodity accounts.
They, too, are children of Asset accounts, with Lots of shares (not
necessarily in integer values/units only), where the price of the commodity
varies over time.

I'm wondering if you can leverage that mechanism to implement inventory
here without such extensive changes.  Maybe just modifying the app/UI-layer
to accommodate Inventory.


 Account-T\ree
 |---Asset
   |---Inventory Account 1
   |   |---lots (goodsA's lots + goodsC's lots)
   |---Inventory Account 2
   |   |---lots (goodsB's lots)

 The only difference of an Inventory Account with other type of accounts
 is: the lots in Inventory Account will have a path goods-guid in its
 slot, pointing to a goods' GUID.
 So in the above example some  of Inventory Account 1 lots will have a path
 goods-guid pointing to goodsA's GUID, an the rest will be pointing to
 goodsB's GUID.

In fact, the goods-guid slot would need to contain a list of the Goods
GUIDs of goodsA and goodsC, right?

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpOE02IwlGGj.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash hangs on older account file

[Josh Sled]

Terry [EMAIL PROTECTED] writes:
 Would it be possible to obtain from some nice folks an older version of 
 gnucash, compiled as a standalone executable so that all the older 
 libraries are not needed?

It's non-trivial to build static executables, especially against old 
libraries.

 Say version 2.0.0

2.0.0 had some serious (read: data-losing) bugs; you do not want to use it.

 It seems that a version that old would have a better chance of reading 
 the 1.8.x account file properly - fewer changes.

This is supposition.

 I could then write a new accounts file with that version and then maybe 
 the current Kubuntu version could read that file.

Please run gnucash from a terminal as follows:

   $ gnucash --debug

... reproduce the problem, and post the resulting /tmp/gnucash.trace file,
along with any output to the terminal.  You mentioned in an earlier thread
that you posted the output, but I'm not sure if/where you were referring
to.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpG3tuhonMik.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Crash in Accounts receivable report

[Josh Sled]

Nigel Titley [EMAIL PROTECTED] writes:
 A freshly built 2.2.99 from trunk on Ubuntu Gutsy gives me the following 
   crash when I click on the Total amount for any line in the Accounts 
 Receivable Ageing report.

 Backtrace:
 In unknown file:
 ?: 0* [gnc:owner-report-create # #]
 In /opt/gnucash/share/gnucash/guile-modules/gnucash/report/owner-report.scm:
   733: 1* [owner-report-create # #]
   715: 2  (let ((type #)) (cond (# #) (# #) (# #) ...))
 ...
   706: 3  (let* (# # #) (gnc:option-set-value owner-op owner) ...)
   710: 4* [gnc:option-set-value #f #swig-pointer GncOwner * -407d6d7c]
 In /opt/gnucash/share/gnucash/scm/options.scm:
   143: 5  (let ((setter (gnc:option-setter option))) (setter value))
   143: 6* [gnc:option-setter #f]
   114: 7  [vector-ref #f 6]

 /opt/gnucash/share/gnucash/scm/options.scm:114:3: In procedure 
 vector-ref in expression (vector-ref option 6):
 /opt/gnucash/share/gnucash/scm/options.scm:114:3: Wrong type argument in 
 position 1: #f

I hadn't yet gotten around to reporting it, but I did see this – as well – in
the Expense Barchart/Piechart reports over the weekend, though the error was
a bit different:

 * 10:51:43  INFO gnc.gui [gnc_plugin_page_report_setup] set needs save
In /opt/gnc/svn/share/gnucash/scm/report.scm:
...
 552: 23  (set! html (gnc:report-render-html report #t))
 552: 24* [gnc:report-render-html # #t]
 518: 25  (if (and (not #) (gnc:report-ctext report)) (gnc:report-ctext report) 
...)
 526: 26  (let ((template #) (doc #f)) (set! doc (if template # #f)) doc)
 529: 27* (set! doc (if template (let* # # # ...) #f))
 529: 28* (if template (let* # # # ...) #f)
 530: 29  (let* (# # # ...) (gnc:html-document-set-style-sheet! doc stylesheet) 
...)
 532: 30* [#procedure #f # #]
In 
/opt/gnc/svn/share/gnucash/guile-modules/gnucash/report/category-barchart.scm:
 552: 31  [category-barchart-renderer # Expense Over Time # ...]
In unknown file:
...
   ?: 32  (letrec ((show-acct? #)) (if (not #) (let* # #) ...) ...)
In 
/opt/gnc/svn/share/gnucash/guile-modules/gnucash/report/category-barchart.scm:
 225: 33* (if (not (null? accounts)) (let* (# # # ...) (letrec # # ...)) ...)
 228: 34  (let* (# # # # ...) (letrec # # # ...))
...
 402: 35  (begin # # # ...)
 431: 36* (if ( (length all-data) max-slices) (let* (# # #) (set! all-data #) 
...))
 432: 37  (let* (# # #) (set! all-data #) (let* # # # ...))
 440: 38  (let* (# #) (gnc:options-copy-values # options) ...)
 446: 39* [gnc:option-set-value ...
 447: 40*  [gnc:lookup-option #f Accounts Accounts]
In /opt/gnc/svn/share/gnucash/scm/options.scm:
1467: 41   ((options (quote lookup)) section name)
1467: 42*  [#f lookup]
/opt/gnc/svn/share/gnucash/scm/options.scm:1467:4: In expression (options 
(quote lookup)):
/opt/gnc/svn/share/gnucash/scm/options.scm:1467:4: Wrong type to apply: #f

The crash is not present on branches/v2.2/.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgp2lXm3gDHCD.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Minor typo in news section section of the home page

[Josh Sled]

Hermann Hüttler [EMAIL PROTECTED] writes:
 in your recent news about the release of 2.2.3 in the section Getting 
 Gnucash it still says Gnucash 2.2.2 .. 

Fixed.  Thanks.
-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpG9Il5Ot9pW.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gnucash-2.2.3 crash during splash page

[Josh Sled]

Jim Parker [EMAIL PROTECTED] writes:
   My first post to this list.  I have found the site very helpful in
 resolving issues I have had with my build of gnucash 2.2.3.  However, now I
 am stumped.

 I completed a relatively clean compile from source of gnucash-2.2.3 and
 during the startup the splash screen shows up and I get the tip of the day
 and various style sheets are loading.  During that process, the program
 crashes with the following output to the terminal.  I'm unfamiliar with the
 code and was hoping someone could point me in the right direction for things
 to check:

 Cheers,
 --Jim

 Backtrace:
 In current input:
1:  0* [gnc:report-menu-setup]
[…snip…]
 ...
?: 15  (letrec (# # #) (do () # #) (cond #) ...)
?: 16* (case fc ((#\l #\l #\h) (set! type-modifier fc) (must-advance)))

 unnamed port: In procedure memoization in expression (case fc (# # #)):
 unnamed port: Duplicate case label #\l in expression (case fc ((#\l #\l
 #\h) (set! type-modifier fc) (must-advance))).

See http://bugs.gentoo.org/show_bug.cgi?id=196417.

In short, you need to get a version of guile and a version of slib that play
nicely together, installed in the right order.  Since slib especially is
really dependent on distributions doing the right thing at install-time, this
can be non-trivial. :(

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpzwBB2UmtGz.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GNC-2.2.3 test error

[Josh Sled]

N. Peguiron [EMAIL PROTECTED] writes:
 Currently using GNC-2.2.0; built it happily from source; test suite ran 
 OK with all tests passed. Congratulations and many thanks to the GNC team.

 Now I'm trying to build GNC-2.2.3 from source. Build is ok, but test 
 suite crashes with following output tail (21) :
 make[6]: Entering directory 
 `/usr/src/gnucash-2.2.3/src/register/register-core/test'
 gcc -DHAVE_CONFIG_H -I. -I../../../..-pthread 
 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   
 -I../../../../src/test-core -I.. -Wdeclaration-after-statement 
 -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -g -O2 -Wall -Wunused 
 -Wmissing-prototypes -Wmissing-declarations  -Wno-unused -MT 
 test-link-module.o -MD -MP -MF .deps/test-link-module.Tpo -c -o 
 test-link-module.o test-link-module.c
 mv -f .deps/test-link-module.Tpo .deps/test-link-module.Po
 /bin/sh ../../../../libtool --tag=CC   --mode=link gcc -pthread 
 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   
 -I../../../../src/test-core -I.. -Wdeclaration-after-statement 
 -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -g -O2 -Wall -Wunused 
 -Wmissing-prototypes -Wmissing-declarations  -Wno-unused   -o 
 test-link-module test-link-module.o 
 ../../../../src/engine/libgncmod-engine.la 
 ../../../../src/app-utils/libgncmod-app-utils.la 
 ../libgncmod-register-core.la -lpopt -lm  -lm
 mkdir .libs
 gcc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include 
 -I../../../../src/test-core -I.. -Wdeclaration-after-statement 
 -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -g -O2 -Wall -Wunused 
 -Wmissing-prototypes -Wmissing-declarations -Wno-unused -o 
 .libs/test-link-module test-link-module.o  
 ../../../../src/engine/.libs/libgncmod-engine.so 
 ../../../../src/app-utils/.libs/libgncmod-app-utils.so 
 ../.libs/libgncmod-register-core.so /usr/lib/libpopt.so -lm  
 -Wl,--rpath -Wl,/usr/lib/gnucash
 /usr/lib/gnucash/libgncmod-gnome-utils.so: undefined reference to 
 `xaccFreqSpecSetDaily'
[…]
 /usr/lib/gnucash/libgncmod-gnome-utils.so: undefined reference to 
 `xaccFreqSpecSetMonthly'
 /usr/bin/../lib/libgnc-backend-file-utils.so.0: undefined reference to 
 `xaccSchedXactionSetFreqSpec'
 /usr/bin/../lib/libgnc-backend-file-utils.so.0: undefined reference to 
 `xaccFreqSpecFree'
 /usr/lib/gnucash/libgncmod-gnome-utils.so: undefined reference to 
 `xaccFreqSpecCompositeAdd'
 collect2: ld returned 1 exit status
 make[6]: *** [test-link-module] Error 1
 make[6]: Leaving directory 
 `/usr/src/gnucash-2.2.3/src/register/register-core/test'
 make[5]: *** [check-am] Error 2
 make[5]: Leaving directory 
 `/usr/src/gnucash-2.2.3/src/register/register-core/test'
 make[4]: *** [check-recursive] Error 1
 make[4]: Leaving directory 
 `/usr/src/gnucash-2.2.3/src/register/register-core'
 make[3]: *** [check-recursive] Error 1
 make[3]: Leaving directory `/usr/src/gnucash-2.2.3/src/register'
 make[2]: *** [check-recursive] Error 1
 make[2]: Leaving directory `/usr/src/gnucash-2.2.3/src'
 make[1]: *** [check-recursive] Error 1
 make[1]: Leaving directory `/usr/src/gnucash-2.2.3'
 make: *** [check] Error 2
 Tried to compiled on 2 different box, on one with gcc-4.1.1 for 
 gnome-2.14 and on the other with gcc-4.2.2 for gnome 2-18. Same result.

The nature of the error above is that your gnucash-2.2.x build is linking
against gnucash-2.0.y libraries installed into /usr.  2.0 had these
FreqSpec-related symbols, and 2.2 does not.

How did you invoke configure and make, here?  What distro/OS/version are you 
using?

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpSfgXBg1RM2.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: data export with Excel 2003

[Josh Sled]

Jannick Asmus [EMAIL PROTECTED] writes:
 I am new to this list. I hope the following can be a valuable contribution to
 some of you.

 I have attached an Excel2003 file for exporting data out of GC to Excel. It

Committed as r16901.  I've put the file in contrib/ with most of the
explanation here in a README file in the same directory.  Thanks!

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpYccWDluXT6.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Patch to support displaying commodities per currency in scatter graphs.

[Josh Sled]

Joshua Ross [EMAIL PROTECTED] writes:
 This patch adds an extra option to scatter graphs that in effect inverts the
 prices.  It allows plotting of commodity per currency.  Mainly useful for
 currencies, although someone may find a use for it with shares.

Applied as r16903.  Thanks!

(In the future, it'd be nice if diffs were based against the top-level of the
source tree, preferrably by `svn diff` or a suitable equivalent.  It's handy
to be patch to pipe the patch into
( cd ~/stuff/proj/gnucash/trunk; patch -p0 - )
without needing to inspect it to see where to apply it.)

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpvAyHvwPcuP.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GNC-2.2.3 test error

[Josh Sled]

PLEASE remember to CC: the mailing list on all replies, using your mailer's
Reply To List or Reply To All feature.

N. Peguiron [EMAIL PROTECTED] writes:
 Josh Sled wrote:
 N. Peguiron [EMAIL PROTECTED] writes:
 Now I'm trying to build GNC-2.2.3 from source. Build is ok, but test suite
 crashes with following output tail (21) :
 snip
 gcc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
 -I../../../../src/test-core -I.. -Wdeclaration-after-statement
 -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -g -O2 -Wall -Wunused
 -Wmissing-prototypes -Wmissing-declarations -Wno-unused -o 
 .libs/test-link-module test-link-module.o
 ../../../../src/engine/.libs/libgncmod-engine.so
 ../../../../src/app-utils/.libs/libgncmod-app-utils.so
 ../.libs/libgncmod-register-core.so /usr/lib/libpopt.so -lm  -Wl,--rpath
 -Wl,/usr/lib/gnucash
 /usr/lib/gnucash/libgncmod-gnome-utils.so: undefined reference to
 xaccFreqSpecSetDaily'
 snip
 make: *** [check] Error 2

 The nature of the error above is that your gnucash-2.2.x build is linking
 against gnucash-2.0.y libraries installed into /usr.  2.0 had these
 FreqSpec-related symbols, and 2.2 does not.
 Yes, you've caught it ! But as I am building this new release in a working
 directory (/usr/src/gnucash-2.2.3) and I have not yet installed it, I don't
 understand why this gcc command links against a library which is supposed to
 be not yet installed.

 Of course, my old Gnucash-2.2.0 is still in operation; I do not have
 uninstalled it. Should I ?

You shouldn't need to, no.  Most devs regularly build from somewhere under
$HOME, and install into something like /opt/gnc/svn/…. I personally did all
2.2 work (including the FreqSpec - Recurrence switchover and removal) with
2.0.5 installed normally in /usr/.

Perhaps the issue is that the build location is itself /usr/, for some reason?


 How did you invoke configure and make, here?  What distro/OS/version are you 
 using?
 ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --with-gconf-schema-file-dir=/etc/gnome/version/gconf/schemas
 make
 make check  check.log 21

 My distro is Beyond Linux From Scratch (BLFS) for i686-pc-linux-gnu
 SVN-061209, kernel 2.6.18.3 and SVN-071229, kernel 2.6.23.12.
 According the LFS book, most of user packages are installed with
 --prefix=/usr. The configure command above is the one recommanded by the BLFS
 book for Gnucash-2.0.0.

That configure string seems reasonable.


N. Peguiron [EMAIL PROTECTED] writes:
 Josh Sled wrote:
[…]
 The nature of the error above is that your gnucash-2.2.x build is linking
 against gnucash-2.0.y libraries installed into /usr.  2.0 had these
 FreqSpec-related symbols, and 2.2 does not.
 True. If I rename the existing /usr/include/gnucash and /usr/lib/gnucash
 directories before the new 2.2.3 build, both make and make test run smoothly.

 Using the existing old libraries should be prevented when building the new
 release.

I'm pretty sure nothing in the GnuCash sources can affect this, so much as
your system's build toolchain really determines which libraries get pulled
in.  But I'm not a build expert.

What version of automake are you using?

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgp1OJueKY0fH.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Plot details - barchart reports

[Josh Sled]

Davide Imbeni [EMAIL PROTECTED] writes:
 I would like to change slightly the appearance of the plots in bar-chart
 reports.
 As it is now it's a bit difficult to get an idea of the level of the bars (a
 part from the first one on the left), so I would like to add a grid to the
 plot or, even better, have the actual numeric values visible (e.g. when
 clicking on the corresponding bar, or when pointing it without clicking, or
 even as a label close to it)

These things would be provided by modifying how we call libgoffice, which
provides the actual plotting.  The primary binding code between gnucash and
goffice is in src/gnome-utils/gnc-html-graph-gog.c.

The interface between the reports and that code is through a couple of
levels…

The report (scm code) will emit an object tag with param tags for the
various parameters.  See src/report/report-system/html-barchart.scm.

GtkHtml is configured for object tags (with a particular class-id) to be
handled by the aforementioned gnc-html-graph-gog code.  It then parses the
params/data, and converts it into goffice's interface, and renders the report
into a pixmap.  The pixmap is then returned to GtkHtml as the rendering of
the object tag.

 I don't know anything about scheme, guile, and extremely little about html,
 and before continuing my research, I would like to get directions and
 suggestions from the experts.

 Where to start from? Do I have to dig into scheme? Shall I create a custom
 report or change something in the stylesheet?

- Make sure you know what's supported by goffice, and the details of what it
  needs (for, say, labels on chart segments).
- Modify the pie/bar-chart generator code for those new parameters.
- Modify the gnc-html-graph-gog code for those new parameters.
- Modify the reports to use the new pie/bar-chart generator code.


We're here and happy to help if you have any questions.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpwUi1k9isHg.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Plot details - barchart reports

[Josh Sled]

Davide Imbeni [EMAIL PROTECTED] writes:
 I will just report what I found so far on the subject, after some
 digging and a lot of learning, and why I think I will now suspend
 further investigations.

This is unfortunate (especially after your very good looking initial patch),
but thanks for the followup! :)


 One additional question: I found hardly any documentation on the
 goffice library, and got the impression it is only used by gnucash and
 gnumeric. Have other alternatives been considered? Which could they
 be, and why have they been discarded (apart from backwards
 compatibility / least effort )?

Not really.  Guppi was known dead, and Gnumeric was already doing graphing.
Since we already share dependencies, c, it seemed low-impact to use goffice,
which was known to work (having proved itself in gnumeric) and would easily
slot into a gtk environment…


Care to suggest an alternative?  One that I've seen before is Grace¹, but I
didn't really look into it too deeply.

¹: http://plasma-gate.weizmann.ac.il/Grace/

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpC1CuJ1BMoJ.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: cannot find -lgnc-backend-file-utils

[Josh Sled]

Derek Atkins [EMAIL PROTECTED] writes:
 By any chance are you running make -j 2  (or make -j with any
 number  1)?  I only ask because it's possible that there's a
 race condition and it's trying to build the second library
 before the first.

No, the gentoo ebuild forces make -j1 to prevent this, and I confirmed that
Martin did not override that.  (There's a bit in the logs to that effect,
with a bit more embellishment if anyone cares.)

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgptJfrIotCho.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: import QSF?

[Josh Sled]

Keith Bellairs [EMAIL PROTECTED] writes:
 I did an export COA to QSF, then noticed that the import is not there.
 (Using a recent SVN build of trunk.) A quick search suggests that the import
 was turned off at the time of the 2.0 release. Is it dead? Should there be
 an export without an import? Or did I just happen into the middle of a work
 in progress?

QSF was the brainchild of a previous developer, who's since left the project.
The QSF importer was exceedingly buggy, so it was disabled.  You should
consider it dead.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgp8obBnrZYDc.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Query

[Josh Sled]

Jiaan co [EMAIL PROTECTED] writes:
 hello GNUcash, I plan to use this software for my own business, just for 
 credibility, may i please have at least five well known companies that uses 
 this software? thank you and good day.

I don't think we have such a list.

You'd probably do better soliciting such a response on the gnucash-user
mailing list.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgppCnqbHwDyx.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: File imports

[Josh Sled]

Easton Christian Family Centre [EMAIL PROTECTED] writes:
 You currently offer the ability to create by importing Quicken (.QIF) files.
 Are you considering going to the next stage and offering compatibility with
 QuickBooks.

I just considered it, and it would be grand!  :)

Unfortunately, the QuickBooks file format is not documented in the same way
that QIF is.  And over the years that people have wanted QuickBooks import,
no one has contributed the code to do it.

So, I'd suggest re-entering your data, or starting with a new data file in
GnuCash at the next convenient opportunity.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpaQSocXaVTN.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Bug 105932

[Josh Sled]

Charles Day [EMAIL PROTECTED] writes:
 I added this question/comment to this really old bug, but I'm not sure that
 anyone will see it unless I also post it here. Christian or Derek, perhaps
 you could respond, since your comments (from four years ago) are on the bug.

 Nearly four years later... the documentation still doesn't cover
 this. If this is a documentation issue, shouldn't it be reassigned to
 the Documentation component? Or, if the dialog itself needs to be
 redesigned to be simpler to use, I'm open to suggestions.

Is it going to get fixed because it's moved the Documentation component?

Personally, I'd say the QIF Import component is more correct, reflecting that
adding documentation is rarely the right solution … a more clear UI is; a
patch that made it more apparent in the UI how to create a new Account
wouldn't need documentation.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpNoh2RObObq.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: rtl reports

[Josh Sled]

Ori Hoch [EMAIL PROTECTED] writes:
 I am trying to create rtl (right-to-left) reports for the hebrew translation
 of gnucash.

Awesome. :)

 I created a new stylesheet (stylesheet-plain-rtl.scm) and I tried to change
 some html attributes, I can change the align attributes for table cells, but
 I can't add a dir=rtl attribute, how can it be done?

I'm not sure if GtkHtml supports @dir on td.  AIUI, when you export the
source on the report-generated HTML, we actually ask gtkhtml to generate the
source from its internal representation of the HTML.  And as GtkHtml has a
limited understanding of HTML (especially HTML  3.2), it probably doesn't
parse it in the first place.

But, it does look – as you notice – like GtkHtml has some RTL support
overall.


 Another strange thing - if I look in the source of any report with any
 stylesheet, there is a p dir=rtl surrounding the entire body, I couldn't
 see where this comes from, I guess it's added if the locale is hebrew - but
 where does it come from? I did a search for 'RTL' on the entire gnucash
 source and it's not there, so it must come from somewhere else.

This, too, looks like GtkHTML from a cursory glance at the 3.8.2 sources I
have lying around.  It seems to understand @dir on html, body and p.


 One more thing.. I can see how a specific report is defined, but where is
 the entry point for actually rendering it. Where is the scheme file that
 calls the 'renderer which was defined in (gnc:define-repot ... )?

It's a bit of a nightmare ... src/report/report-gnome/window-report.c (which
is not otherwise used anymore for the UI side of reports; see
gnc-plugin-page-report.c instead) sets up a stream handler of url-type
report to be the callback gnc_html_report_stream_cb.  I believe this is
called anytime the GtkHtml widget needs to obtain the stream of content to
parse/render/c.

This callback calls
[src/report/report-system/gnc-report.c:] gnc_run_report_id_string()
which calls
[ibid:] gnc_run_report()
which calls
[src/report/report-system/report.scm:] (gnc:report-run)
which calls
[ibid:] (gnc:report-render-html)
which obtains the renderer and the stylesheet and retains the html.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpyuuYbUYohZ.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GDA: Status

[Josh Sled]

Derek Atkins [EMAIL PROTECTED] writes:
 Previous, Graham said:

 Users needs win I am afraid, if necessary I'll patch gnucash to do it
 myself.

 Hahahahahahaha!!  Wow, now you're REAY funny!   Have you
 forgotten that GnuCash is a Volunteer effort?  *laughs*  Users?
 While it's true that it's always nice to have a good user experience,
 the code was written by developers generally for their own use.
 The business features certainly qualify here.  My personal philosophy
 here is you get what you pay for.

Derek, I'm not sure what you hope to accomplish by laughing at people who
want to make the app better, and advocate for users, but it's really
off-putting.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgp9FS2ZDiOST.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gnucash XAC file XSDs

[Josh Sled]

Graham Leggett [EMAIL PROTECTED] writes:
 In order to parse the gnucash XAC file from java, I have generated the
 following XSD files using Trang called from Oxygen XML.

 The XSD was generated from my company's XAC file, with additional entries
 added to make sure none of the fields were missed. While it works for me so
 far, it might need some tweaking to be useful for everyone.

How does this reconcile with the hand-generated Relax-NG schema in
src/doc/xml/gnucash-v2.rnc?

If we're going to keep a non-authoritative schema, I'd prefer we have just
one, and convert to the other formats.  Though I don't care much, I'd
strongly suggest the much more human-friendly Relax-NG compact syntax for
that.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpgjH3dH4hZd.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: XML file backend

[Josh Sled]

Phil Longstaff [EMAIL PROTECTED] writes:
 Josh, does the sx code need a separate template commodity per account?  
 Should the account xml parser use dom_tree_to_commodity_ref() to merge these? 
  Should the sql backends only merge currencies, not any other commodities?

No, they don't need to be separate per account.  They're just placeholders
for engine constraints to hold; when the template is instantiated, the
commodities on the template splits are set to be relevant for the accounts
involved.  I don't see reason why currencies should be treated specially.

A commodity with identity of (namespace,id) should (be able to) have an
immutable, single instance in the system that's shared by all referrers.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpY1xT7RgZfp.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Trac and MediaWiki question

[Josh Sled]

(I hope you don't mind; I've CC:'d this to gnucash-devel.  I'm glad I caught
the message, too: lame mail filtering on my side had stuff to
[EMAIL PROTECTED] going to the spam folder. :/ )

Sean Colombo [EMAIL PROTECTED] writes:
 I noticed GnuCash is using MediaWiki instead of the Trac wiki.  This makes a 
 lot of sense, but I was wondering if you have been able to hook them together 
 at all?  Just about the only benefit of
 using the internal Trac wiki seems to be that you can link right from Tickets 
 and Changesets to wiki pages and from wiki pages to Changesets and Tickets.  
 Is there some sort of extension for trac
 that allows you to do this with MediaWiki?

Nope.  We decided early on to just not use the Trac wiki or ticketing
systems, since we had investments in media wiki and bugzilla.gnome.org.
There might be some sort of integration plugin/addon for Trac or mediawiki,
but I've not even looked for one.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpJF2KbsZQgT.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Compile Fails in qofsession.c

[Josh Sled]

Casey Cichon [EMAIL PROTECTED] writes:
 After a few weeks away from using the development gnucash version to 
 upgrade my machine from Fedora 5 to Ubuntu gutsy (soon to be hardy).  I 
 get this when running 

 cc1: warnings being treated as errors
 qofsession.c: In function 'qof_session_save':
 qofsession.c:1214: warning: 'msg' may be used uninitialized in this function

 i used the following configure line 
  ./configure --enable-compile-warnings --enable-ofx --enable-doxygen

 is something broke that I just missed in the emails.

You're now using a different compiler, which generates a warning on that line
where the previous one did not.  By default, we run gcc with '-Werror', which
promotes warnings to errors.

You can choose to fix the warning in qofsession.c, or ./configure with
--disable-error-on-warning, which will keep building in the face of the
warning.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpetGG6aChl0.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Differences between tar.bz2 and tar.gz package

[Josh Sled]

Yan Li [EMAIL PROTECTED] writes:
 I've downloaded both the .tar.bz2 and .tar.gz packages of GnuCash
 2.2.5, and to my surprise, their contents are different! Please see
 the attachment.

There was no attachment to this message; can you please resend?

 Which one should I trust? Or anything wrong with my network?

 One more thing: now packages' signatures are not released along with
 the packages. I think it's still necessary for the vast users to have
 a way to check the integrity of such a great piece of software.

This is unfortunate.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgptAfraro1K9.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: How to compile the latest version of GnuCash with database support on MS Windows

[Josh Sled]

Ajit Kumar [EMAIL PROTECTED] writes:
 I am new to GnuCash and currently evaluating it to see how best I can use it
 for my finance needs. Also, I need the backend to be based on a database.
 Upon reading through the document, I came to know that PostgreSQL is
 supported but not as a default backend. 

  

 Could anyone guide me through the steps to build GnuCash with the back-end
 database support? Also, does GnuCash support MySql/Oracle database?

There is no pre-alpha version in which a postgres or any other database
backend is available, much less supported.

Instructions for building on Windows can be found at
http://wiki.gnucash.org/wiki/Windows#Instructions_for_an_.28almost.29_automated_build.
 I
don't see why they wouldn't apply to the gda-dev branch, where the most
recent DB-related efforts are taking place, except I don't think building on
Windows is a goal for that branch, right now.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpMRITPvfswg.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GNUCash Startup Files

[Josh Sled]

Stephen Grant Brown [EMAIL PROTECTED] writes:
 Under Vista, I uninstalled GNUCash, checked that there was no C:\Program 
 Files\gnucash subdir, reinstalled gnucash 2.2.5 into C:\Program 
 Files\gnucash and restarted gnucash.

 It found the datga files that I am using.

 Where did gnucash get this informatin from? Ie what file did gnucash look at 
 to find that I had a data file in C:\Users\Public\GNUCash Data?

This information is stored in gconf, under the key /apps/gnucash/history/,
and the ./file0 key specifically.

 I suspect that this config fille is corrupted and expected it to be delted 
 when I unistalled GNUCash.

If you just want to ignore this file, then start gnucash with the --nofile
option.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgp1pk0kiMD0D.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: need help with program

[Josh Sled]

Jessica Goulding [EMAIL PROTECTED] writes:
 I am having trouble with my gnucash software.  I hope this is the place to 
 get help.  

The gnucash-user list is more appropriate.

 When I try to open my saved account hierarchy to continue work, I get this 
 message: 

 Can't parse the URL C:\Documents and Settings\Owner\.gnucash\books\Gnucash 
 heirarchy.20080705110931.20080705125724.log.


 If I go down the list within the Books folder, by chance I may be able to 
 open something, but it is not the most recent save.  How can I simply open 
 gnucash and get the most recent accounts information?  I really don't want to 
 set it all up a third time!

You've saved your datafile in $HOME/.gnucash/books/, which is a directory for
Gnucash to manage its state, not for you to save stuff in.  Likely, your
datafile is already trashed, but maybe there's a backup…

The timestamped .log files are not the ones to be looking at.  Try to find
the latest timestamped .xac file in that directory.  If it's of a non-trivial
size, it's hopefully a good backup as of the timestamp.

Move it to a different folder, and rename it to get rid of the timestamp and
whatever. Then open gnucash and File  Open that file.  After that, gnucash
should remember that path, but you can always open the file directly.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgp0c8nKeJLpi.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash software

[Josh Sled]

All of this is more appropriate for the gnucash-user mailing list.

Hotel Plein Ciel [EMAIL PROTECTED] writes:
 1)  Register me as user and request you to send me, if any, registration 
 code.

There is no registration process or registration code.

 2)  I wish to sibscribe in your mailing list members.

Mailing lists can be subscribed to at 
https://lists.gnucash.org/mailman/listinfo.

 3)  Can you please inform me if it is possible to Import/export accounting 
 data in Microsoft EXCEL 2003

No; there's no facility to read Excel files, and there's not really a fixed
structure of accounting data to import.  Your best bet is to convert the data
into QIF or OFX, and use the importers.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpj74G7Kyo59.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Scheduled Transactions

[Josh Sled]

Tom Browder [EMAIL PROTECTED] writes:
 I would like to see the scheduled transactions (sx) capability
 enhanced (see enhancement bug # 521285) to be more like Quicken.  I
 would like to see a split-pane in the account window showing due and
 buttons to push like 'enter', 'edit', and 'skip'.

 I would like to see the same buttons in the sx editor along with a
 choice of seeing sx for each account on separate tabs.

 And of course I will work on this myself (with helpful comments from
 developers).

 Thoughts?  Feasible?

Sure.  I separated out much of the application logic from the UI in the
last go-round in order to support things like this; see
src/app-utils/gnc-sx-instance-model.{c,h} in particular.

Why is a split-pane in the Account tab better than the existing
since-last-run (SLR) dialog (or maybe moving that dialog into a tab)?
Do you really need to see both things at once (a main motivation for a
split-pane)?  Otherwise, I fear the page wouldn't be big enough to see
either.

What's the benefit of splitting up the upcoming transactions across
separate tabs (by account)?  Instead, maybe, allowing an Account-based
filter on the existing SLR page?

One thing that people regularly ask for is – in the editor for a
particular SX – to see the upcoming instances, so that they may quickly
schedule something forthcoming.  This should be pretty easy to do, by
simply generating the instance model through some configurable date in
the future (30 days?  60 days?  drop down?  as a function of the
frequency of the SX?).  Unfortunately, there doesn't seem to be a way to
just generate the instance model for a single SX, but that should be
straightforward to add in.

Anyways, I'm happy to help, but my response time might not be very low.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpgrkS8Sq1eJ.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash-fr is dead ?

[Josh Sled]

raf...@free.fr writes:
 I post this mail here because I had send a mail to gnucash-fr, three times in
 three weeks, and it is not yet on the mailing list!

 Why ?  Is the moderator of gnucash.fr busy ?

Are you subscribed to the list?

I don't believe there is a moderator of gnucash-fr.  As far as I know,
I'm the only person doing mailing list moderation, and I only do so for
-user and -devel.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgpDneBrJSpXC.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Sugestion

[Josh Sled]

Joao Freire jlmfre...@gmail.com writes:
 The RSS feed in the site does not work.
 It should be linked with the news.

The Atom feed had a minor validation problem due to some messed up
charset transcoding, which I've corrected.  At this point, it's valid
Atom 1.0 
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.gnucash.org%2Fatom.php#l364.

Does it work for you, now?

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgpTT0dQcvorF.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: report html generation question

[Josh Sled]

Arthur Ralfs art...@mathbrane.ca writes:
 Why is this?  I would much rather get the scheme generated html than this.

I believe we ask gtkhtml to do the export, and it serializes its own
representation of the document rather than emitting the generated html.
I'd agree that it's less than ideal, but such is the reporting
subsystem. :/

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgpi4GgBVApW2.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: report html generation question

[Josh Sled]

Arthur Ralfs art...@mathbrane.ca writes:
 Since the opinion of GtkHTML does not appear to be high in this context
 I presume
 there must me some other reason for its use.

History/legacy use.  In the mean time, the resurgence of competition
between browsers has led to more options.  GtkWebkit is probably right
up there, maybe embedded mozilla/gecko, too.

 Does it seem to be very difficult to change its use in generating
 reports?  Can anyone
 point me to the code where it's invoked?

src/gnome-util/gnc-html-*

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgpBJYfynciRE.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash reports via eguile - probably not

[Josh Sled]

Chris Dennis cgden...@btinternet.com writes:
 Thinking it through, even if it were possible to pass parameters to the 
 template code, we'd be opening a huge security risk.  We'd be 
 encouraging Joe User to create a template containing code that has full 
 access to the workings of GnuCash.

There is no security risk here.  The software does and should have full
access to the software.


 What is really needed is some sort of wiki-like markup that can be 
 parsed by Guile code and includes references to GnuCash objects. 
 Something like this (I know the 'variable' names I've used are very 
 un-GnuCash-like), for which I've used TiddlyWiki-like markup:

I'd encourage you to not add another layer of formatting or
translation.  Just have the template iterate over objects, call
accessors and format data for rendering.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgpBtPB3h3hme.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash reports via eguile - probably not

[Josh Sled]

Chris Dennis cgden...@btinternet.com writes:
 Josh Sled wrote:
 Chris Dennis cgden...@btinternet.com writes:
 What is really needed is some sort of wiki-like markup that can be 
 parsed by Guile code and includes references to GnuCash objects. 
 Something like this (I know the 'variable' names I've used are very 
 un-GnuCash-like), for which I've used TiddlyWiki-like markup:
 
 I'd encourage you to not add another layer of formatting or
 translation.  Just have the template iterate over objects, call
 accessors and format data for rendering.
 

 Can you explain exactly what you mean by that last sentence please?

I meant specifically skip the idea of having any sort of wiki formatting
or anything else.  So the template would look more like (guessing at the
semantics of the TiddlyWiki-like markup, which I don't know):

  h1Invoice #?scm:d (invoice-no-format invoice-no) ?/h1
  h2?scm:d company-name ?/h2
  address
?scm:d company-address ?
  /address
  table class=invoice bordered
thead
  tr
thDate/th
thDescription/th
thQty/th
thCost/th
thTotal/th
  /tr
/thead
tbody
  ?scm (map (lambda (inv) ?
tr
  td?scm:d (format-date (gnc:invoice-get-date inv)) ?/td
  td?scm:d (gnc:invoice-get-description inv) ?/td
  td?scm:d (gnc:invoice-get-quantity inv) ?/td
  td?scm:d (gnc:invoice-get-cost inv) ?/td
  td?scm:d (gnc:invoice-get-total inv) ?/td
/tr
  ?scm ) report-invoice-list) ?
/tbody
  /table
  strongTotal:/strong ?scm:d accumulated-total ?br /


But more importantly, as you point out, binding all those symbols is
critical to getting any approach working.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgpZHFdT6uXu9.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Register rewrite

[Josh Sled]

Charles Day ceda...@gmail.com writes:
 I had a quick look at the register-rewrite branch. My first impression is
 that the original register code has not been changed at all and that some
 kind of new stuff based on GtkTreeView was being worked on. Is it the
 intention to abandon a GUI-independent register design for a Gtk+ dependent
 version?

Yes, as I recall the idea was to be concrete in terms of a GTK-specific
implementation.

I never really followed the work closely, but I'd like to say that the
branch was 90% of the way there.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Domain Model for GNUCash

[Josh Sled]

 Mike King mikek...@mikekingcourses.com writes:
 If there is no domain model as such, then I would create an entity model. The
 only difference is that one uses entities instead of classes. All other
 structure is the same.

Graphical entity models are basically useless except as documentation
and meeting/discussion fodder.  CASE tools are a distraction.

If you want to help, bug fixes and patches to the code are more
worthwhile.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgpFBtq8KggJi.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New Splash Screen Graphic

[Josh Sled]

Tynan ty...@betterthanyourboyfriend.com writes:
 I don't really know anything about open source, but I've been enjoying
 using GnuCash, and I thought I'd try to help out by making a new splash
 screen graphic. I have attached it for your consideration. The software
 is very professional, but the graphic looked cobbled together to me.

Yes, it's quite nice. :)

Can you also please provide the original/source vector file(s) to assist
any future modifications that might need to be made?  As well as
specifying a GPL-compatible license for your contribution?

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgpLdhDG4uRrn.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Scheduled Transactions as Unscheduled Templates

[Josh Sled]

Havard Rast Blok n...@hblok.net writes:

 I recently sent out this on the user-list, however did not receive any
 answers (only two, me too), so I thought I'd try here.

  Original Message 
 Subject: Scheduled Transactions as Unscheduled Templates
 Date: Mon, 18 May 2009 09:22:23 +0200
 From: Havard Rast Blok n...@hblok.net
 To: gnucash-u...@gnucash.org

 Hi,

 The automatic transaction history of GnuCash is one of my favourite
 features, and scheduled transactions takes this one step further: now
 only a single number is all it takes to complete a transaction.

 However, not all reoccurring transactions follow a defined schedule.
 Take paying for postage or stamps as an example: It happens frequently
 with different amounts, but is usually not scheduled. When I need to
 enter a transaction of this type, I'd still like the power of the
 template functionality, though. Then I can type in only the gross
 amount, and the rest (VAT, etc.) is filled out automatically.

 I've browsed several threads, wiki and docs, but cannot find any way to
 set up an unscheduled template. Is it worth a feature request?

It's been a feature request for a long time, though perhaps informally.


Havard Rast Blok n...@hblok.net writes:
 Well, here's my first simple, but perhaps naive, suggestion:

 In the current Frequency tab of the Edit Scheduled Transaction window,
 add an entry to the list of Frequencies: Never. The rest of the UI in that
 tab would then be disabled (gray?).

 To recall the template, use the current auto-complete functionality for
 previous transactions. If the new Description auto-completes and matches a
 template, bring up the window Since Last run... to enter the custom
 fields. (Might want to rename the title of that window, though.)

 What do you think? Too simple? Confusing? Or worth a try?

Popping up a (new) dialog to solicit a set of named values from the
user, and then creating the relevant Transaction … is not hard.  It's
probably easier than misusing the SX UI code to do so, actually.

I'd approach it from the other direction: you really want to promote the
existing implicit templates that auto-complete starts to surface into
a first-order, explicit UI concept.  Forget about scheduled
transactions, and focus on the templating.

Maybe after you have it working where the template set is scheduled
transactions with frequency=none, you can improve it by making the
templates have their own identity … have a way in the UI to explicitly
CRUD named templates … separate storage in the data file, c.

Hooking into the autocomplete code to do what you want is not going to
be easy, I don't think.  You might want an explicit Transaction 
Create From Template, maybe which popups up a text entry which has
autocomplete over the available-template names.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgpbohe2Pk0EI.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Sorting out QSF import and export

[Josh Sled]

David Goodenough david.goodeno...@linkchoose.co.uk writes:
 So the question is, which way to go.  Should I simply work on the old QSF
 code and get it to work, and then add selection to it and matching, or should
 I look at the new framework and rewrite the QSF code to work there?

QSF is a bad idea.  Please don't propagate it.

Domain-specific import/export formats and import/export logic are going
to be far easier to implement, debug and use.

Hopefully, you can find something to leverage in the existing (generic,
not QIF-specific) importer/exporter, but for things like Customers and
Vendors where there's not an src/engine/Account to match against, I'm
not sure if the existing code will be trivially adaptable; those Vendors
and Customers are different data-sources for matching purposes.

Note that I'm speaking at a high-level, I'd be happy if you found the
code was more sophisticated than I'm thinking.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgp4PPD0rfnHX.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Sorting out QSF import and export

[Josh Sled]

Derek Atkins warl...@mit.edu writes:
 David Goodenough david.goodeno...@linkchoose.co.uk writes:
 Where is the GNC XML format defined?  I have some ideas that I have
 used elsewhere to fix the GUID problem.

 It's defined in the sources.  see src/business/business-core/xml

There's a non-normative post-hoc schema in src/doc/xml/gnucash-v2.rnc,
as well.

 The existing code was pretty sophisticated in that you could plug
 in various matching rules per object and such.  But it was very buggy,
 and it's been a long time since I've looked at it.

 Are you talking about the QSF code, or the other import/export code?

 QSF..  in the merge code.  dialog-merge?  druid-merge?  Something like that.

src/gnome/druid-merge.c, lib/libqof/qof/qofbookmerge.c.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgpNe5CLwuTDK.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: RSS

[Josh Sled]

Derek Atkins warl...@mit.edu writes:
 Please remember to CC the list on all replies using your mailer's
 Reply-To-List or Reply-All functionality...

 Brian Wilson dragoncharme...@gmail.com writes:

 I know that there hasn't been any new news. However, when I open the feed
 location in my browser (Firefox) I still ought to see a list of the past news
 items. When I open the list the page is blank. Additionally, my Live Bookmark
 fails to load.

 I'm afraid I don't use the RSS feed so I can't help you, but the
 website is up so the only potential issue would be broken html
 within a news item.   The actual RSS feed code hasn't changed.

(FWIW, the feed is not RSS, but Atom.)

There is a XML parse error due to the presence of HTML-only entities:



js...@phoenix [~/tmp]$ curl http://www.gnucash.org/atom.php;  gnucash-atom.xml
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 515540 515540 0  32147  0 --:--:--  0:00:01 --:--:-- 40276
js...@phoenix [~/tmp]$ xmllint gnucash-atom.xml 
gnucash-atom.xml:45: parser error : Entity 'acirc' not defined
lt;ligt; Bug #582976 acirc; install.sh - webkit-1.1.5-win32.zip is not av
  ^
gnucash-atom.xml:47: parser error : Entity 'acirc' not defined
lt;ligt; Bug #583883 acirc; Customer report produces errorlt;/ligt;
  ^

Someone should clean up the news item(s) HTML to not do that.  Patches welcome.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgp11bwZmUJFS.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: RSS

[Josh Sled]

Robert Stocks robert.sto...@gmail.com writes:
  090607-2.3.1.news  contains two places where the - char is not the -
 char  but is the – one - which is invalid (the feed generator is
 howere not escaping that correctly.

 the easy fix to the source file.

Fixed.  Thanks. :)

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgpNcrGpbjKgV.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: DBI backend tests

[Josh Sled]

John Ralls jra...@ceridwen.fremont.ca.us writes:
 Yeah, don't. That is, don't actually talk to the real databases, just  write
 a trivial pretend database (they're often called mocks) with the  same
 function signatures and header names and so on so that you can  build your
 test program with it instead of with pgsql or mysql.  (Trivial so that the
 mock database doesn't need to be tested itself.)  Ideally you should do the
 same for sqlite.

I would only recommend this if you find that using (one of the) real DB
backends (sqlite, and against a /dev/shm-based db in particular) for
day-to-day testing is not fast enough.  Maintaining an ad-hoc
persistence backend is a huge PITA … in many systems, though, it's less
of a PITA than a disruptively-long-running testsuite.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}


pgp7uK1PrQoeg.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: DBI backend tests

[Josh Sled]

Phil Longstaff plongst...@rogers.com writes:
 There's no problem doing this for sqlite3 (just use /tmp/X).  However, 
 since there are differences for mysql and pgsql, I'd like to perform the test 
 for all 3 databases.  Any ideas on how make check could/should get urls for 
 a mysql and pgsql database server to use (or determine that there is no 
 server available, so skip that check)?  Argument to make check i.e. make 
 check -DMYSQL_URL=...?

./configure --test-mysql-url=… --test-pg-url=… ?

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Client--Server Implementation Model.

[Josh Sled]

Rishikesh Shukla sequester1...@gmail.com writes:
 Dear JOSH:
 ==

 Here i need your help, you sounds like a coding guy, and believe that
 earlier you were actively involved writing codes. Well i have gone through
 the link that you provided, But i could not found any of the page which
 provides the data flow digram and ER Digram as well. so can you provide any
 such docs or links.

The auto-generated docs available in the source code at and at
http://cvs.gnucash.org/docs/HEAD/ may be useful to you.  I don't
believe any data flow or E/R diagrams have been contributed.  I'd
suggest starting with the Engine module and working out from there.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gnucash software

[Josh Sled]

Derek Atkins warl...@mit.edu writes:
 Marina Carvalho marimari...@hotmail.com writes:
 So, the reason why I'm writing is to check if it's ok to offer Gnucash for
 download in our website so the students can have access to it.

 Of course it is.  GnuCash is licensed under the GPL, so you're free to
 redistribute it as much as you want.  Just keep in mind that we're
 always releasing updates so you might need to keep on top of it.  Also,
 I'd recommend that you only re-distribute the Stable (2.2.9) release, not
 the testing (2.3.x) releases.

Note that if you are distributing the program in binary form (such as
the windows binary), you must abide by the terms of the GPL, and also
make available (and offer for) the source code.  See
http://www.gnu.org/licenses/gpl-2.0.html#section3 for the exact
details.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: programming gnucash in scheme

[Josh Sled]

On Thu, Jun 21, 2001 at 01:46:12PM -0400, Jonathan A Rees wrote:

| I'm having a difficult time getting started programming gnucash in
| Scheme (Guile).  I found 
|   http://gnucash.org/lxr/gnucash/source/doc/guile-hackers.txt
| but it doesn't really tell me enough.

One of the best texts on Scheme [and computer programming in general] is
Structure and Interpretation of Computer Programs, by Ableson, Sussman
and Sussman... this is the text for intro CS at both MIT and Berkeley [and
certainly other unis]... niftily-enough, it's available on the web nowadays:

http://mitpress.mit.edu/sicp/full-text/book/book.html

The archives should have other pointers on useful sites/texts.

| 1. How do I start a Guile read-eval-print loop that's connected to
| gnucash?  What's the best way to load Guile code into gnucash?

I'm not a gnucash-guile-guru [G^{3}? :)], but I'll explain what I know...

First, there's a --eval switch to gnucash [at least in 1.6.0] which
will let you eval single scheme statements; I believe this exists in
earlier versions as well.

I also see --load, which *ahem* Load[s] the given .scm file [from
src/scm/command-line.scm], which you might want to check out.

| 2. What are the gnucash-related procedures I get to use from Scheme?
| The constructing custom reports page of the 1.4.9 documentation
| refers to a source file src/g-wrap/gnc.html, which I am unable to find
| in the online source tree at gnucash.org.

Well, first off, I'd really start with the 1.6.0 codebase... it's
a) current and b) improved. :)

There are two classes of things you can access from Gnucash's scheme:

. scheme-defined functions [src/scm/*]

. g-wrapped functions, which you can find in src/guile/gnc.gwp, which
  defines the wrappers around the c-defined functions.

And, indeed, the reporting stuff is a good place to look... especially
the current [1.6.0/CVS] reporting stuff.

| I'm interested in accessing the engine -- the GUI stuff doesn't
| interest me (yet).

Well, I my experience is C-focused, but I've seen that when the register
goes to save a tranaction you've modified, it does so in a scheme
procedure... so there's certainly at least some[, and I'd venture to say
complete,] access to the engine...

Cheers...
...jsled
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

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

[Josh Sled]

On Sat, Jun 23, 2001 at 07:13:11PM +1000, Conrad Canterford wrote:

| 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

I've never seen QuickPOS, so I'm curious... I'm guessing it's a
Windoze-based program which provides a full-screen user interface for
the management and operation of a point-of-sale environment.  To this,
it provides transaction entry [and eventual payment processing], and
integration with a product database.  Since it's got a product list,
it may also perform inventory tracking and ordering...?

| WHAT I WANT

| - interface to gnucash ('cos that is where my accounts are).

What form does this interface take?  Does this mean that transactions
entered in GnuPOS show up in the appropriate registers in GnuCash... and
other registers exist in those books for dealing with non-POS business
expenses [like rent/utilities bills and paychecks and such]?

| - configurable gui ('cos not everyone wants things looking the same).

What do people really want to configure in the UI?  Seems like they'd
mostly want to customize logos and colors, and maybe some customization
of transaction flow... go from the ring-up screen to a payment-type
screen, then to a receipt/finish screen.  Some installs might want a
customer information screen in there, or maybe a rewards-program
screen in the mix...  does this seem right?

With respect to this, I'd say that customer information/loyalty tracking is
probably an important [maybe future-] aspect of a POS system.  Security is
very important, here, depending on the nature of the information being
collected.

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

Seems like it should simply be configurable for most applications... 

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

OT: seems like a springs-and-struts layout option wants to exist in GTK...
but I digress.

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

At the same time, you don't want each user to have to go through a large
amount of work each time re-creating the stock screens, and especially
their input-handling.  I'm thinking here that you want to major elements
in the state-machine description/configuration file.

. Stock screen with configuration/modification descriptions.
. Novel screen definitions, which become/create an Identifier for the
  state machine.

Similarly, there should be a simple way for the standard keys/transitions
to be used... default actions, perhaps.

Seems like out of that you end up with a set of widgets like item
entry and name/address entry that can be combined to create screens,
and these have standard navagition and navigational transitions in the
state-machine file.

Said another way, the state machine XML file for a really standard POS
environment shouldn't need to contain anything more than the customization
elements [logos, colors, c].

Just a few other stock widgets you might consider:
. appointment setup
. customer contact information entry/modification
. order/purchase-order generation [for ordering from suppliers]
. inventory lookup
  . I'm thinking video store title-lookup
  . I'm also thinking we expect this thing we're out of to be delivered
on Tuesday lookup.

| - ultimately, some way is going to have to be found to encrypt the data.

This might devolve into just use a cryptographic file system argument
at some point.  OTOH, it's nice not to have that dependency, especially
if the focus is on simplicity for the probably-non-technical end-user.
OTOOH, if the idea is a turn-key system installation, the cryptographic
file system can already be setup and hidden from the end-user.

The standard issues apply here: it should be strong enough that losing the
password will make the data unreadable [all security _does_ rest in the
key], but some procedure exists for a lost key to be recovered.  Maybe this
is where a trusted third party can come into the picture, to hold one half
of a key-share that can only be combined with a non-secret key-share that
the user holds [and can write down or whatever w/o compromising security],
which would allow the user to prove identity to the third-party in order
to get their keys back.

The 

Re: scheduled transactions

[Josh Sled]

On Mon, Jun 25, 2001 at 12:13:11AM -0400, [EMAIL PROTECTED] wrote:

| I've been playing with the scheduled transactions in CVS for a bit.
| I couldn't get the instantiation UI to actually create transactions in
| the specified accounts. Am I missing something, or is this just not
| supposed to be working yet? Still, it's good to start seeing some code.

I've seen it create the transactions, but I haven't thoroughly played with
it; it's definitely not finished.  I think it'll have a big problem with
'once' transactions.

My present tree [which I hope to ./make-gnucash-patch tonight] has
many fixes for recurrance-frequency state saving/restoring from the UI,
which allows me to better play around and test the since-last-run stuff,
which is the next big thing to do... I hope to get to this tonight,
but it doesn't seem highly probable... probably next weekend.

| My initial impression is that I think you have way too much UI.

I like UI. ;)

More seriously, I like visibility.  I want a single dialog which shows me
all the relevant info about a thing, in this case the scheduled transaction
object.  I don't want to cram the editing functionality into the register,
as there's just a different thing going on: you're trying to deal with
this abstracted-transaction which has some not-fixed transaction data,
a recurrance frequency, a start and end date, and a couple of options
about the further handling and creation of it.

I focused on keeping the GNCFrequency widget as compact as possible,
and I think I've gotten it pretty visually small...

But maybe this isn't what you mean when you say too much UI...

| The scheduled transaction dialog needs to exist for editing, but I
| don't think it shouldn't be the primary way to create scheduled
| transactions. I'd like to see the Duplicate button in the register
| copy the selected transaction to the schedule and pop up the
| schedxaction editor to allow the user to specify the frequency.

This is indeed the idea ... some sort of button/context-menu-item
allowing the user to specify/edit this scheduled transaction, a-la
recurring calendar appointments in Outlook/Evo/GnomeCal.   I think that
both approaches should work... and, in fact, there should be two/three
ways to create recurring transactions:

1. Creation through the as-exists SXEditor UI.

2. Right-clicking on any transaction in a register, which will pre-fill most
   of the data in the as-exists SXEditor, including the template
   transaction[s] and making a guess at the frequency spec.

3. Analysis of existing/historical data; if (2) is going to have the
   logic to guess about the template transaction contents and frequency
   specification, then this should be easy.

OTOH, instead of opening up the dozen registers involving scheduled
transaction to see what's coming-up to be created, there should be a
single dialog [like the list, but improved] which shows exactly what and
when things will be created... I've thought about ripping the gnomecal
or Evolution week/month-view widgets out for this purpose, but haven't
thought about it too much.

| Instantiation could be a button or just something that happens on
| startup, out to a pre-configurable (not prompted) number of days in
| the future. 

I'm thinking that upon startup, a last-run-date check is made.  If the
last-run date != today, then we might have scheduled transactions to
create...

If that list is not empty, then we pop up a dialog similar to the present
since-last run dialog.  This would allow the user to:

. See the transactions that were automagically created [based on the
  flags in the SXEditor].
. See the transactions that have come due, and will be instantiated;
  these may require variable bindings, and thus the user is to be prompted
  for those values.
. Maybe, allow the user to select which SXes to defer the creation of.
  I'm undecided on this functionality...

| When run, all the automatic transactions would just
| happen, and the manual ones would happen too but with a new s value
| in the Reconcile field. s transactions would be included in the
| future balance but not the present / cleared / reconciled
| balances. 

I don't think they should be marked 's'... maybe 'f'... but I think even
more correct is that they are marked 'n', and are indicated as being
in the future because they're past the blue line which denotes 'future'
transactions.

| A right-click menu item (Enter ?) could convert s
| transactions to n. It would be nice if the s transactions showed
| with a different background color -- say, light blue as the default.

Yes... I was planning on this [right-clicking on future transactions in the
register to instantiate them]... check src/doc/TODO-schedxactions.  I like
the idea of a differently-colored background for doesn't-yet-exist items.

| I guess the main reason for that whole dialog-nextrun thing is for
| future formula-based transactions. 

Not solely.

I think it's a good thing that unless the user specifies so, there's a

Re: scheduled transactions

[Josh Sled]

On Tue, Jun 26, 2001 at 12:21:26AM -0400, Aaron Peromsik wrote:

| At work, in completely unrelated software, we often focus on the
| number of mouse clicks required to perform common tasks as a measure
| of usability.

Noted... I'd be interested to see your report on how
GnuCash::ScheduledTransactions fares in this study... [ :) ]

| That's useful, but having things in the register in advance is
| differently useful. As for getting it all in one place, that can be
| done in general ledger mode. Not that the dialog is not useful --
| I'd be happy to be able to see things both ways.

That's a good idea; I think the dialog is an appropriate first step,
but that entry via the dialog should feed into the GL so that the user
can make sure that what's about to be created [read: placed in the books]
is correct...

| I'm with you so far, except for the today part. I want to pre-enter
| transactions 30 or 60 days ahead for planning purposes.

Okay... so some version of the current create SXes for some date
into the future dialog will want to persist for something other than
debugging... I'll work this in.

| JS . Maybe, allow the user to select which SXes to defer the creation of.
| JS   I'm undecided on this functionality...
| 
| I'm not! This is the whole reason I want the 's' status on a
| transaction. I'll explain below.

I think I'm talking about something slightly different, here.

When I say defer the creation of, I'm thinking that a particular SX
comes due [utilities bill], but you haven't actually received the bill
yet [the DOM is a Saturday, and you'll get the bill on Monday]... so you
defer it's creation such that it will keep coming up as 'to-be-created'
ea. time you start GnuCash, until you actually have the facilities to
create it [the bill, with the correct amount].

| As far as I'm concerned, 'n' means I have initiated a transaction,
| either by writing a check and mailing it, or performing a transaction
[deletia]
| With this setup, there's no reason for deferred creation as you put
| it. Automatic transactions go in as 'n', and manual transactions
| go in as 's'.

Well, from an implementation and storage standpoint, I think there is
still a reason for deferred creation...

As far as I see and understand what you're saying, there's no call to
interact with the 's' transactions in the register... they're there until --
as you say -- you actually write the check; at that time they're created,
and you fill in the check number and appropriate amount.

Up until that time, many things might change.  You may change the frequency
or the parameters of the SX.  Instead of going through the books, removing
these 's'-status actual transactions, and creating the new ones, I think
it makes more sense to not have created them at all.

This is not to say that they won't appear in the register... the register
should show a user-configurable window of future transactions... but I
think they're not marked 's' so much as they have a ' '/null-reconciliation
field: they're not [yet] transactions, and they don't exist in the books.

However, this would not be appropriate for you, if you intend to run
reports over future transactions... [?].

| What I actually want is for gnucash to enter all my scheduled
| transactions in the register 30 to 60 days in advance. I don't want to
| be prompted. At the point of converting 's' to 'n' is when I want to
| be specifying values.

Noted... I think I'll be able to work this in, though it's a major
difference from how I was thinking that scheduled transactions would be
used; this is good.

I'm thinking that this is analagous to creating transactions which have
come due since the last run and today... now, it's creating transactions
which have come due since the last run and today, but N days out in
the future.  In both cases, the 'last_occur' date and the 'last_run'
dates are valid... just shifted per the SX-configurable create N days
in advance option.

I'm starting to fear that the creation-policy options will be too
cumbersome... I'll code it up and we can see how much is there at the end,
and then make the tough decision about which policy to ignore.

| That's fine... I just meant that when a transaction in the register is
| still 's', a right-click menu could summon a dialog for fiddling with
| the variables.

Yes... indeed.

| I think it may be useful for loan payments. For that case I probably
| would almost never change the precomputed values. I'm not sure what
| else it's good for, maybe you can enlighten me?

I'm thinking multiple roommates... I'm an out-of-college renter with two
roommates.  I pay the bills and subsequently bill my roommates; to this
effect, I have an Assets:Money Owed to Me account for each roommate.
When I get a bill, it goes into splits like the following:

Description   AccountCredit  Debit
---   -  --  ---
PGE  Assets:Cash On Hand:BofA Checking  

Re: post-it notes

[Josh Sled]

On Tue, Jun 26, 2001 at 03:25:08PM -0500, Linas Vepstas wrote:

| I was sitting here, thinking, 'you know what gnucash really needs?
| post-it notes!'   It would be pretty cool to stick one onto 
| some transaction; every time you opened the register, there it would 
| be, a big fat post-it stuck to the transaction, scrolling with it.
| It screams out 'hey you need to deal with this!'

Personally, I hate paper... and thus post-it-notes... and even more so
digital translations of post-it-notes.  

[[ I really like, however, things like http://freshmeat.net/projects/yank/
   ... a good implementation of basically the same concept,
   taking advantage of the fact that you're running on a computer
   [priorities/sorting/hierarchy|info.mgmt.].  ]]

| (this might be particularly appropriate for scheduled transactions
| when they start coming due ...)

Indeed; If it's there, SX can make use of... but the reminders I'm planning
will not expect this [I'm thinking seperate window].

There's also been some call to have SX-related reminders appear in
existing/external todo-lists [think Evo]... this is relatively low on my
priority list ATM, but I can be convinced...

...jsled
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: budgeting

[Josh Sled]

On Sat, Jun 30, 2001 at 10:28:48PM -0600, Larry Hunter wrote:

| I'm new to gnucash, and wanted to know who was currently working on
| budgeting.  

No one, at present.

I started with the intent of working on budgeting [back in Jan], but
decided to get Scheduled Transactions out of the way first, as I believe
budgeting will make use of it.

| Is there any code out there?  I tried browsing the CVS tree,
| and found some design docs, but no code.  

There are further design notes/discussions in the mlist archives [~Nov/Dec
are good places to look], and I have some notes both in my head and on
paper locally which I intend to get to the list when I get a free moment
[maybe between compiles today].

One of the problems with jumping into coding at this point is that some
[read: nearly all :)] of the design/focus is still to be done.  I have
some thoughts revolving around Budgeting Categories [not necessarily 1-to-1
with Expense categories], Budgeting Entries [something like Transactions],
how these can be viewed, and how they interelate.

But many of the puzzle pieces aren't even stamped out into the correct
shapes, let alone pieced together to form the puzzle [how's that for
analogy? :)]...

Maybe the best thing to get this started is your input on how you have
done budgeting [spreadsheet/paper/program-based], and how you _want_
to do budgeting.

| Although I don't have a lot of time for hacking, I am a reasonably
| experienced scheme programmer, and am strongly motivated to help get at
| least some basic budgeting functionality up and running soon.  Is there
| anything I can do to help the project along?  Who should I talk with? 

This list is the best place to talk to for now.  While I've been intending
to do budgeting stuff for a while, I have very little time for hacking
myself... so if you have time now, go for it.

I haven't been intending that the budgeting stuff would be primarily
or significantly in scheme, but I figure that bits of it will be.
But ultimately she who codes, decides.

One thing that I was thinking would be appropriate in scheme, and that
both scheduled transactions and budgeting would be able to make use of
is a historical transaction analyzer...

The Analyzer would process historical transaction data with the goal of
determining correlated transaction [basically those which recurr], and
with what a) frequency and b) parameters.  Parameters are generally the
splits, broken down into b.1.) descriptions, b.2) accounts and b.3) amounts.
The output would be something like:

Transaction:
  approximately every 1 month on the 15th {0.13:14th, 0.75:15th, 0.12:16th}
  Split 1: {0.7:PGE, 0.3:Pacific Gas  Electric}
   Assets:...:Checking
   -$120 +/- $27
  Split 2: {0.82:Utilities, 0.11: Utils, 0.07: Power}
   Expenses:...:GasEletric
   $120 +/- $27

This is only a semi-defined problem as presented here, so let's frame it
a bit more by examples:

1. The user right-clicks on a transaction and says Schedule/Recurr.
   If there are any transactions sufficiently similar [as determined by
   the Analyzer, perhaps via some iteratively-depened similarity-metric
   thresholding], then those become input to a first cut at the template
   transaction and recurrance frequency, which will hopefully save the
   user a large amount of time in setting up recurring transactions,
   especially for people who have already done the data entry.

2. The user has entered/imported a bunch of financial data, and wants to
   start using the imaginary-so-it's-necessarily-super-cool [:)] budgeting
   workbench... there's no reason why they should have to enter anything
   substantial; the program should generate a good first-approximation
   of their scheduled transactions; note that the window of scheduled
   in the budgeting case can even be yearly, as in a savings goal to
   have enough funds with which to buy christmas gifts available in
   approximately November... or a yearly vacation.


Another thing I was thinking would be appropriate for scheme
is a constraint-satisfaction problem solver, as I think budgeting
projections/decisions can be framed as a CSP, and then solved... but this
is kinda blue-sky thinking ATM, so I just put it out as such for now. :)

...jsled
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: QOF help!

[Josh Sled]

On Tue, 2004-05-04 at 17:41, Derek Atkins wrote:

 IMHO doxygen should be the ONLY place for API documentation.
 However if you want to provide usage examples, or architectural
 documentation, docbook would definitely be a reasonable thing.

I'd push for most instances of this type of documentation to be in
doxygen, as well... the closer to the code it is, the higher probability
that it'll actually get maintained in the face of change...

...jsled

-- 
http://www.asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
# A: Because it breaks the flow of normal conversation.
# Q: Why don't we put the response before the request?
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

discussion re: libgoffice scheduling

[Josh Sled]

I wanted to relay the following conversation I had, earlier, with Jody
f/ Gnumeric regarding the split-out _from_ Gnumeric of what's being
called libgoffice.  It'll include stuff like toolbar
foreground/background-color selection, font-selection, c... all sorts
of standard-office-app stuff.  The most important part for gnucash is,
specifically, the GnomeOffice Graphing [GOG] stuff...

In summary: it looks like it'll be a while [~weeks] before the relevant
code is sufficiently split out of gnumeric to be even copied into the
gnucash source tree, and a while after that before the library is
released, let alone started to be included in distros; he's targeting a
6/25 release of libgoffice.


jsled jody: question re: libgoffice/gog.
jsled Any 1-line status update on it?  And what's the best way to monitor it's 
progress so I don't need to bug you.
jsled s/.$/?/
jody jsled: progress is being made
jody I've got GODocument and GODocumentControl in my tree now and have ported 
gnumeric to that
jody that gives me a place to hang to plugins and importers/exporters
jody target is to make the split for 1.4
jody jsled: it will include show/hide toolbar and fullscreen support to start with
jsled jody: followup question about libgoffice.  It sounds like there's a bunch of 
stuff in it that gnucash doesn't care about at the moment.
jsled Frankly, we're probably going to copy the gog sources into the gnucash tree 
for the initial G2 port/release, anyways.
jody jsled: there will be some things in there that it may not care about
jody jsled: I'd ask that you not do that
jody I'm happy to work with you to ensure we release on a schedule that is convenient
jsled hmm.  you can ask, but we're pretty serious about not depending on stuff 
that's hasn't been in distributions for 6-9 months.
jsled We're currently talking about making FC1 our base/ref. platform.
jsled Or _maybe_ making it FC2.
jsled regardless, how long before libgoffice is going to be in out in the field?
jody jsled: before june 25
jody aka guadec
jsled Sorry ... a bit of a rhetorical question.   The point being that there's no 
realistic alternative for our needs besides GOG, but we're hoping to get the g2 port 
out the door before ...
jsled 2004.06.25 + 6m = 2004.12.25.
jsled Now.  I'm not sure that we _will_ do that, but we can only hope for the best. 
:)
* jody scratches head
jody At this point the code is not seperable from gnumeric
jody It still uses the plugins and format/parsing engine
jody both need to move down
* jsled nods
jody It is also based on gtk-2.4
* jsled nods
* jody apologizes for that but there are not alot of choices
jsled Well, so are we at this point... we've moved a good chunk of 2.4 into our 
source tree as well. :/
jsled we'd already had libegg in there, and I've moved a bit more which has showed 
up in gtk-2.4.0...
jody You're going to mix 2.4 code with 2.2 libraries ?
jsled yes.
jody brave
jsled heh.
jsled What's your primary concern with copying the gog code into the gnc tree?
jsled general in-elegance, or...?
jody Limited developer resources
jsled eh?
jody bugs and api requests will definitely occur for what is basicly the first major 
user of the code outside of gnumeric
jody having those appear against an out of date version
jsled hmm.
jody or worse, get fixed there and potentially not get upstreamed ...
jsled yes.
jsled point well taken; we will take care to find a way to prevent that.
jody Where is your cvs hosted ?
jsled cvs.gnucash.org -- private box in MA.
jody If it's on gnome.org you could do a virtual module include
jody svu: I'm nost sure what the question is ?
jsled a solution might be for the developers / early testers to actually develop 
against libgoffice ... but then cut-off a version when we're nearing the end of our 
dev/release cycle.
jsled there will undoubtedly be bugs after that, but we'd be a better position to 
manage the patches then.
jsled In any case, we'll have to deal with that at some point in the future... but 
will keep it in mind.
jsled jody: permission to copy this conversation to the other primary GnuCash 
developers?
jody jsled: sure, and I'll extend an invitation to get cvs hosted on gnome.org
jody which would simplify importing things easily 


...jsled

-- 
http://www.asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
# A: Because it breaks the flow of normal conversation.
# Q: Why don't we put the response before the request?
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: QOF help!

[Josh Sled]

On Tue, 2004-05-04 at 17:50, Derek Atkins wrote:

 I'm not sure how to use doxygen for architectural docs...  Could you
 provide an example or pointers to docs that describe it?

http://www.stack.nl/~dimitri/doxygen/commands.html

Using \defgroup , \addtogroup , \example , \mainpage and \file , and a
bit of convention, one could build higher-level structural docs
along-side the lower level file/function/variable docs.

...jsled

-- 
http://www.asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
# A: Because it breaks the flow of normal conversation.
# Q: Why don't we put the response before the request?
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: More KMyMoney peeking: is our file format clearly documented?

[Josh Sled]

On Thu, 2004-06-24 at 11:13, Derek Atkins wrote:

 While I agree that's an issue, the reason I said that I understand why
 they don't is that about 60-70% of the code in gnucash is UI code, and
 much of that has reliance on gnome/gtk.  The lines between UI and
 non-UI have been blurred significantly (certainly outside the engine).

Yes; as a contributer to this problem, I'm looking forward to finding
ways to fix it.  The G2 port needs to be completed, first, however. :/


 I also believe that there are TOO MANY shared libs in gnucash.  Why
 are gnc-modules, the engine, and app-utils all in separate libraries?
 Nobody else is using gnc-modules (and why should they!?)..  And
 app-utils doesn't work without the engine..  I see no point in that
 separation.

Yes.  While we're on the arch. topic, what else should be removed?

* engine subsumes app-utils
* delete gnc-modules
* g-wrap moves to swig
* reports move from guile-generated to embedded-guile.
  * embedded generic script?
[* remove Scheme entirely]



  In particular, the goal of the gnucash engine has (always) been to 
  provide a GUI-neutral, indeed, OS-neutral way of accessing financial 
  data through a well documented, supported API.   This GUI neutrality
  is what allowed the Motif and GTK versions of GnuCash to co-exist,
  and even helped start a KDE port, back when, until it withered.

Yes, but as mentioned there's too much useful code in the higher-level
and directly in the GUI code.  We can refactor it down into an
abstracted engine and people have been actively doing that.  But until
then it's hard to say that it's practically possible to write a QT/KDE
front-end.


 Sure, but the engine is a fairly small portion of the code..  The only
 potential reason I can think of for someone NOT to use it is that it's
 HARD to just get the engine code.  Playing devil's advocate here...
 It depends on glib (which is a gnome library)..  

Well, glib is pretty unencumbered beneath it; if depending on glib is a
problem ... well ... you probably have bigger fish to fry.


 Back to reality, and having dealt with the code myself, I can
 certainly understand the frustration with trying to re-build the qt
 frontend.  Gnucash just has too much crap in it.  :)

Yes.  We need to get the Gnome2 port done ASAP, and then start the
distillation of GnuCash.  Smaller, Faster, Leaner.  Simplicity.

...jsled

-- 
http://www.asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: More KMyMoney peeking: is our file format clearly documented?

[Josh Sled]

On Thu, 2004-06-24 at 09:18, Derek Atkins wrote:

 *SIGH*
 
 It would've been nice if they just decided to write a Qt frontend
 to GnuCash, but I can certainly understand why they don't.

Likewise... :/

 Nope, we don't have current DTDs for our XML data.  It would be nice
 if we did, but there had been little reason to create them as the xml
 code isn't dtd-driven.  HAD the xml code been DTD-driven it would've
 been nice

I don't really know what DTD-driven [XML [un]marshalling] code means
... nothing jumps out to me as the right way to do that.

[ The key thing is mapping the element names  to in-memory
data-structures and the and leaf-node values to lexical
value-representations [i.e., a GncNumeric for 50 = 50/1], which the
DTD can't represent. ]


Frankly, the way we do things on the parsing side is a pretty readable
approach:

struct dom_tree_handler spl_dom_handlers[] =
{
{ split:id, spl_id_handler, 1, 0 },
{ split:memo, spl_memo_handler, 0, 0 },
{ split:action, spl_action_handler, 0, 0 },
{ split:reconciled-state, spl_reconciled_state_handler, 1, 0 },
{ split:reconcile-date, spl_reconcile_date_handler, 0, 0 },
{ split:value, spl_value_handler, 1, 0 },
{ split:quantity, spl_quantity_handler, 1, 0 },
{ split:account, spl_account_handler, 1, 0 },
{ split:lot, spl_lot_handler, 0, 0 },
{ split:slots, spl_slots_handler, 0, 0 },
{ NULL, NULL, 0, 0 },
};

?

I wish the generation side was as direct, data-driven and -- ideally --
the same.  But even it is pretty readable, as well.

I'd encourage the KMyMoney people to just UTSL ... specifically
src/backend/file/gnc-*-xml-v2.[ch] is the place.

...jsled

-- 
http://www.asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]

___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

gnome2 graphing status

[Josh Sled]

A small update on the status of graphing in the gnome2-branch...

So, I've been looking into the gnome-office-graphing [GOG] stuff, and
noticed that it doesn't have a feature of guppi we were using, which is
the ability to bind the graphical region associated with a data-series
element to an action ... in the case of gnucash ... with the appropriate
register being opened in response to a bar-section or pie-wedge being
clicked on.

Warlord and I had breifly talked about just porting guppi to gtk2, but
I'm not sure how feasible that is in the long term.


I just had an irc-conversation with Jody Goldberg, where the following
became clearer:

* some of the lingering gnumeric dependencies that prevent libgoffice 
  from being seperated out are actively being addressed.

* he's targeting having a seperate libgoffice for the Gnumeric-1.4 
  release, in September.

* gog doesn't yet have interactivity... there are a couple of 
  stabs at supporting the identification of plotted elements based on 
  x,y coordinates w/in the view, but they're neither ideal [at least, 
  Jody's not happy with them] nor finished.

* gnumeric wants GOG to have some measure of interactivity; other apps 
  do, too, so it will eventually get written...

* he wants to eventually get to something like guppi's toolkit 
  interface.  This feels like overkill to me for GnuCash.  He's 
  anticipating handling a large set of the integration issues after 
  that's progressed forward some more.


In any case, it sounds like being a consumer of gog is going to help
shape it's evolution... 

I'm really looking for something on the order of:

setupGraph (...)
{
GogDataSeries dataElts = gnc_data_series_from_accounts(...)
GogGraph graph = GogGraph( dataElts )
gog_register_callback( graph, activated, cb_activated )
add( window, graph )
}

cb_activated ( GogGraph graph, GogDataSeriesElement elt )
{
GncAccount *act = (GncAccount*)get_user_data( elt )
gnc_open_register_for_acct( act )
}

Depending on having a better handle on the time frame in the future, I
might try to simply extend the existing [though incomplete] mechanisms
that GOG has in order to allow the above pattern, even though they can
safely be considered deprecated right now.   It'll depend on when we can
get momentum to get a future release out the door, of course.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnome2 graphing status

[Josh Sled]

On Fri, 2004-08-13 at 11:28, Chris Lyttle wrote:

 Does this mean we're actually beginning to discuss a possible timeframe
 for a release of gnucash-gnome2? If the dev's believe they are getting
 closer to a point when the can actually say 'yeah we could aim for a
 certain date depending on these things being solved' then I would have
 some incentive to begin working on updating the docs for gnucash-g2.

I don't feel like we're at that point; I would think that a gnome2 port
is at least 4-6 months away, given the current level of effort. :/


 I am, however, in agreement with Christian here. Dropping some features
 in order to get the port out the door would be a good thing imho. There
 will be, of course, a set of features that cannot be dropped without
 seriously setting back GnuCash, but perhaps now is the time to start
 looking at what those features are and realistically what we could leave
 on the floor to be reintroduced at a future release?

Yes, I'd agree with that, as well.  It would certainly be more
desireable to get GOG-without-interactivity out sooner rather than
accepting a delay to wait for a more featureful GOG ...

Presently, though, we do need to block at least until GOG [plus
libgoffice, it seems] is factored-out from gnumeric [in the
Sept/gnumeric-1.4 timeframe].

Given however long it will take to resolve the other issues, the world
might be in a very different place regarding GOG features.


After report/graphing, it sounds like the biggest single open issue
remaining is the set of register UI issues.   At the same time,
reviewing GNOME2_STATUS ... there are still a lot of miscellaneous open
issues throughout the project ...  menu items missing, features mostly
working, c.  Hopefully it won't be the death of a thousand papercuts
... but we do need steady, app-wide progress to get them resolved.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Adding a from and thru date to a register report

[Josh Sled]

On Mon, 2004-08-16 at 09:44, Andy Czerwonka wrote:

 Is there any simple way to add a from and thru date to a register report?  I'm 
 using 1.8.8.

I'm curious ... I generally think of transactions as occuring at some
point in time, and having two dates [transaction vs. posted].

Why a time-range?

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Adding a from and thru date to a register report

[Josh Sled]

On Wed, 2004-08-25 at 09:06, Derek Atkins wrote:
 Josh Sled [EMAIL PROTECTED] writes:
 
  Why a time-range?
 
 This report covers transactions from 2004-01-01 through 2004-06-30

Ah ... report, not transaction.  Got it.

Presently sticking no email before coffee note to monitor...
...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New XML file format for QOF?

[Josh Sled]

On Fri, 2004-10-29 at 04:48, Neil Williams wrote:

 The main difference is that I would like to use the XML for data interchange 
 between QOF applications and to make the format more like a simple bag than a 
 tree:

bag vs. tree isn't really the problem, is it?


What's wrong with your palm conduit just writing out gnucash's existing
format?  There's no requirement that the palm conduit use gnucash's data
model or object hierarchy...

 ?xml version=1.0?
 qof-bag-v1
 qof:count-data cd:type=book1/qof:count-data
 qof:book version=1.0.0
  book:id type=guidc0dd5ca1b11338f3ceae57f6e0106d75/book:id
  qof:count-data cd:type=qof-expenses1/qof:count-data
  qof:object version=1.0.0 type=qof-expenses
   obj:desc type=qof-expensesPilot-link QOF expenses/obj:desc
   obj:id type=guidc9c3c49db198b3b87e8d513e618f9078/obj:id
   obj:date type=expense_date1099016941/obj:date
   obj:int32 type=type_of_expense7/obj:int32
   obj:int32 type=form_of_payment2/obj:int32
   obj:int32 type=currency_code1/obj:int32
   obj:int32 type=expense_amount32/obj:int32
   obj:int64/
   obj:boolean/
   obj:string type=expense_vendorCompany Name/obj:string
   obj:string type=expense_cityCity Name/obj:string
   obj:string type=expense_attendeesNames/obj:string
   obj:string type=expense_noteAny string content/obj:string
   obj:gnc_numeric
obj:gnc_numeric_enum/
obj:gnc_numeric_denom/
   /obj:gnc_numeric
  /qof:object
 /qof:book
 /qof-bag-v1

* do you really mean bag, or just collection?

* the outer element isn't namespaced [qof:bag?]

* the -v1 isn't really necessary -- that could very well be in the 
  namespace.

* the version=x.y.z is probably not necessary, either...

* is a book a first-order concept in QOF?  If not, how does the 
  serialization layer know about books?  How does it get the 
  namespace declaration from the application layer?


 This way, the XML can hold any compatible QOF data.

I suggest you take a look at RDF, which attempts to do something
similar, but I think more effectively.  At least some of the things
they've addressed should be present in this.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Run a Wiki on www.gnucash.org?

[Josh Sled]

On Fri, 2004-11-19 at 09:31, Derek Atkins wrote:
 [EMAIL PROTECTED] (Linas Vepstas) writes:
 
  My #1 concern is security; that enabling a Wiki will allow a system
  compromise.  
 
 A fair enough concern, but that could be an issue for any piece of
 software.  You're already running a web server, so a wiki on top of
 that is not a completely new system.

Hmm.  Except when the software on top of the web server opens new
vulnerabilities by evaluating it's parameters using shell tools without
proper value checking...

My own twiki installtion and web-hosting account was hacked last night,
so this problem isn't theoretical. :(

As well, wiki-spam is a fscking nightmare, I'd -- unfortunately --
recommend some sort of access control on top of the wiki. :(  Or maybe a
light-weight change-approval procedure.


In any case, I do think we should get a nice and simple wiki, sandboxed.

Obviously, Linas, it's your box and hosting call, though.   If you don't
want to host it, perhaps we can alias 'wiki.gnucash.org' to some cheap
3rd party service provider?

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: The GnuCash core

[Josh Sled]

On Mon, 2004-12-06 at 14:42, Derek Atkins wrote:

 for personal use I really don't see the average user being able to
 install, conifigure, _AND SECURE_ a web server in order to run a
 personal finance manager.

An embedded webserver makes a lot of that go away ... 

But I'm not sure if that's what Paul's after.

 Having said that (see, I'm trying not to be insulting ;) you could
 write another interface around the gnucash API.  You'd in effect need
 to re-implement all the UI pieces of gnucash, but you could do it.  I
 don't know how hard it would be, nor how much time it would take, or
 even what the integration would look like.  But anything is possible,
 it's just a SMoP (Simple Matter of Programming).

Paul, one thing to note is that a lot of the generic application logic
is built in the UI layer, very close to the UI pieces.  There's just a
lot of semantics there intertwingled with GTK button press-handling.

Very welcome would be a set of changes that helps seperate those two
things more cleanly: it'd not only help with other UI-frontends [Qt,
console, c.], but would generally improve the internal organization of
gnucash.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: The GnuCash core

[Josh Sled]

On Mon, 2004-12-06 at 15:28, Paul Dunbar wrote:

 Well there are a few reasons I'm going for something web-based.
 
 I want to provide a personal finance management system to the small
 number of users of my website, mostly for myself, but people have
 seemed interested in this idea when I talk about it.  In that sense my
 target audience isn't so much end users as it is web administrators
 who would be interested in providing PFM features to their users (I've
 seen finance.yahoo.com and heard of MSN providing something like this,
 though not to a full extent).  

Well, to be clear: GnuCash is a single-user application right now, so
depending on what types of features you want to offer there might be
some more work attached.

 I want something that runs commands on
 a schedule (like bill payments, alerts, importing bank transactions,
 reconciling, etc.), and it seems to makes sense to use a server for
 this since a server is supposed to be always on.  

Note that  Scheduled Transactions _only_ supports Transactions ... not
imports, reconciliation, alerts, or anything else.

At the same time, it would be useful to factor the Scheduled aspect
out from the Transaction aspect [or any other system-actor], however. 
So not only is there the refactoring, but also the adapters between the
scheduling core and those other subsystems.  As well, in order to allow
those features to run in a scheduled/unattended manner, there's probably
a whole task+params subsystem, too...

 I also want this for
 platform independance, I would like to login to an SSL site and input
 transactions, check balances, etc. without going through the trouble
 of X11 forwarding or transferring data. 

Yeah, web apps do indeed rock. :)

 If I do decide to use the gnc api for this,  I plan to do my own UI
 stuff, as well as reports and things like scheduled tasks (All though
 I might try to see if I can't marry my idea of using cron with gnc's
 scheduled payments system).

Well, I hope and believe that if you're going to go forward and want to
leverage GnuCash, that there can be some mutually beneficial overlap in
the work.  For instance, it would probably be more time-efficient to 
factor the non-UI business logic out from the UI-servicing components
into a layer on top of the engine, rather than have a web-based
front-end re-create the _entire_ UI.

Plus, the existing reporting code _already_ generates and renders HTML,
so it makes much more sense to simply have that generate better HTML
[and better-handle charts, c.] than re-create the reporting subsystem.

 btw I appreciate you not insulting/shooting me down on this though, I
 know it seems a little impractical and a LOT ambitious, but I think
 with proper watering and plenty of sunlight, this could be really
 useful. :)  I haven't been doing development for longer than a couple
 of years, but I think I can put something decent together IF I use the
 right design and have useful criticism.

Not impractical at all, though there is a lot of work there.

A web-based front-end to gnucash has been desired for quite a while; in
fact, one of the original design ideas was as a web-based front end.  

Practically, however, there is a lot of effort that has been spent
creating the desktop-environment user interface widgets that make
financial-data-entry work really well.  These days it wouldn't be
impossible to recreate work-alike widgets in javascript, and leverage
some of the nicer script-accessible features [the XmlHttpRequest object,
for instance] available in modern browsers to have a dynamic web
front-end to GnuCash's core.

I would hope that that front-end could sit beside a traditional and
desktop-native front-end, on top of the same engine.  It'll take some
coordination to get there, but it's worthwhile.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: libgnomecanvas backed gnc_item_edit vs. GtkEntry

[Josh Sled]

On Thu, Dec 23, 2004 at 10:21:59AM -0500, Chris Shoemaker wrote:

| I noticed that the g2 branch fails to indicate cursor position when
| typing in an account entry.  I also read the note about this in
| GNOME2_STATUS.  Looking at gnucash-item-edit.{ch}, or really
| src/register/register-gnome/* for that matter, I see that GncItemEdit
| (among other similar things) is backed by GnomeCanvasItem.  Obviously,
| this works.  But it seems pointlessly complex.

There's some amount of design motivation behind the register [and
register-gnome] that's not exactly clear to me either.

I believe the current desires are best captured by: get thing working
under gnome2 first, then later get things working right.

| I'm still trying to understand the character of the G2 port, too.  I
| get the fix bugs goal (e.g. cursor won't show), but would making
| GncItemEdit backed by GtkEntry be in accord with the goals of the g2
| port?  I'm kinda walking in blind here, so someone let me know if I'm
| missing something.

It is fundamentally backed by a GtkEntry; the GnucashItemEdit can wrap a
couple of gtk widgets [a combo box, for instance], but it primarily wraps
the GtkEntry.  The reason it's a gnome canvas item is that the register
is a gnome-canvas, which takes gnome canvas items.  I've been thinking
about just how bad it would look/feel if the register-gnome was just raw
gtk layout-managers + widgets ... but any experiments I was thinking of
performing along those lines would be after the gnome2 port is completed.

The appropriate signals and actions should be proxied to the gtk entry as
much as possible.  It's a bit less clear to me why the cursor isn't showing,
as it's generally unclear to me right now how the damaged-area painting is
supposed to be handed there.

Derek's response is right on, though: if you can find a different solution
that works while both reducing complexity and not regressing functionality,
that's a good thing.

...jsled

-- 
http://asynchronous.org/jsled/
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: libgnomecanvas backed gnc_item_edit vs. GtkEntry

[Josh Sled]

On Thu, Dec 23, 2004 at 07:18:50PM -0500, David Hampton wrote:

| On Thu, 2004-12-23 at 18:16 -0500, Josh Sled wrote:
| 
|  I've been thinking
|  about just how bad it would look/feel if the register-gnome was just raw
|  gtk layout-managers + widgets ... but any experiments I was thinking of
|  performing along those lines would be after the gnome2 port is completed.
| 
| I had been planning to try and rewrite the register as a GtkTreeView
| once the gnome2 port is done.  ISTR there was some reason why I needed
| gtk-2.4 instead of 2.2, but the reason eludes me at the moment.

The GtkAction stuff, I'd imagine.  At this point, we can probably un-egg
it and just claim 2.4 as a straight dep, given it's been out since March
and the g2 port won't be done for a couple/few more months...

...jsled

-- 
http://asynchronous.org/jsled/
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building gnucash with gtk2

[Josh Sled]

On Wed, 2004-12-29 at 07:47, Maykel Moya wrote:

 Can someone point me out to the correct gtk2 tree ?

As per http://gnucash.org/en/hacking.phtml, the branch name is
`gnucash-gnome2-dev`.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building gnucash with gtk2

[Josh Sled]

On Wed, 2004-12-29 at 10:35, Michael Burkhardt wrote:

 cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs/cvsroot checkout
 gnucash-gnome2-dev
 
 There is the error:
 cvs server: cannot find module `gnucash-gnome2-dev' - ignored
 cvs [checkout aborted]: cannot expand modules
 
 Is there a solution?

Use the correct command:

% cvs checkout -r gnucash-gnome2-dev gnucash

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Running gnome2 branch

[Josh Sled]

On Wed, 2004-12-29 at 12:49, Maykel Moya wrote:

 I successfully build and installed gnucash gnome2 branch, but when i
 launch it, the old gnucash (i have installed it too) is what is runned.

* Where did you install the gnome2 branch?  i.e., what did you give as 
  the '--prefix' argument to `autogen.sh`?
* What is the output of `which gnucash`?
* What is the output of `which gnucash` --version?
* What command are you using to start the installed gnome2 version?

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

gnucash simplification [WAS: Re: dialog-options vs. glade]

[Josh Sled]

On Tue, 2005-01-04 at 11:04, Chris Shoemaker wrote:

 Planned Direction:
   Specifying my options dialog in scheme was nifty. (I could
 even control layout with the sort order field.)  But I can't seem to
 get it to work for even a date type option, and I eventually visioned
 having a FreqSpec option, too, which isn't already supported by the
 options.scm.  Therefore, this seems like it might be a dead-end.

The options stuff has always seemed like a bit of magic without [enough
of] a commensurate reward.  It's really easy to define a dialog like
that in glade, and populate it with run-of-the-mill editing widgets. 
The callbacks for those widgets can easily enforce constraints and
update a data-model object.

   Here's another approach that might work: Specify my options
 dialog using glade; handle property push/pull myself.

Hey, that works well, and is what every other project does. :)  Glade's
really good at layout, and the code can then be well split between the
view [GTK-handling] and model [gnucash] bits if you try for that.

 Reflection:
   I guess I was led down this road by
 gnc-plugin-page-account-tree.c, which does use
 gnc_build_options_dialog_contents(), but if I look more closely, I see
 that this page's options don't work anyway. :(

Is that fact in the GNOME2_STATUS file?  [It doesn't appear to be :(]

   I knew that there would be a learning curve for gnucash
 hacking when I started -- and it is _large_.  On the bright side,

The curve is WAY too large.  We need to simplify the codebase.  This
should be a priority soon after the gnome2 port is finished ... it's
what I'm looking forward to, anyways.

Specifically:

* invert reporting framework [HTML files with language 
  escapes/templating, not HTML-generating scheme code].
* strip out module system.
* main() in C which loads scheme, not the other way around.
* removing g-wrap dependency.
* simplify register, especially in terms of UI-event handling.
* consistent naming conventions.
* [eventually] removing scheme entirely.

* better split application-logic from UI-handling.

Others?

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Financial calculation

[Josh Sled]

On Sun, 2005-01-02 at 01:39, saher edris wrote:
 Does the calculation process for i with the following parameters known
 (p.v.,f.v.,payment,period,pf,cf) in case of a lease transaction being
 affected in case of multiple balloons .

I can't really parse that sentence, but I think the answer is: yes.

That is: if you make non-scheduled payments, the mortgage/loan druid
does _not_ calculate the correct payments.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Finance::Quote

[Josh Sled]

On Thu, 2005-01-06 at 06:29, Michael Curtis wrote:

 I guess there's some further hard-coded information in gnucash which has a 
 list of sources.  Where might I find this...?

Unfortunately, these lists are hard-coded into the gnucash engine
code; specifically, look at:

gnucash/src/engine/gnc-commodity.h
gnucash/src/engine/gnc-commodity.c
gnucash/src/engine/commodity-table.scm

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Advice on creating custom report for GST

[Josh Sled]

On Wed, 2005-01-05 at 09:20, Benjamin So wrote:

 So the question is what is the best way to get my hands dirty in 
 writing custom reports. I'm sure this topic must already have been 
 covered in an earlier discussion, but I didn't have much luck searching 
 the archives. Is there some sort of tutorial to get me started? I have 
 a reasonable amount of programming knowledge, but none of it is in 
 Scheme. I saw a reference to the Hello World report, but was unable to 
 find the corresponding source file. In any case, a simple tutorial 
 would be very useful, is one exists.

I don't think there's a tutorial or how to...

Scheme/lisp is pretty straightforward; there are plenty of good
resources on the next about it that google will help you find.

The hello world report is in 

  gnucash/src/report/utility-reports/hello-world.scm

which on my distro is installed into 

  /usr/share/gnucash/guile-modules/gnucash/report/hello-world.scm


A report basically consists of two parts: an options-genearator which
allows the reporting infrastructure to manage the report's options [both
UI and persistance], and the report-renderer which outputs HTML.  This
may change in the future, but probably not substantially.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Advice on creating custom report for GST

[Josh Sled]

On Thu, 2005-01-06 at 09:13, Josh Sled wrote:
 On Wed, 2005-01-05 at 09:20, Benjamin So wrote:
 
  So the question is what is the best way to get my hands dirty in 
  writing custom reports. I'm sure this topic must already have been 
  covered in an earlier discussion, but I didn't have much luck searching 
  the archives. Is there some sort of tutorial to get me started? I have 
  a reasonable amount of programming knowledge, but none of it is in 
  Scheme. I saw a reference to the Hello World report, but was unable to 
  find the corresponding source file. In any case, a simple tutorial 
  would be very useful, is one exists.
 
 I don't think there's a tutorial or how to...

I spoke too soon; see the bottom of
http://gnomesupport.org/wiki/index.php/GnuCashUsing

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Advice on creating custom report for GST

[Josh Sled]

On Fri, 2005-01-07 at 00:21, Benjamin So wrote:

 directory structure up to C exists on my local disk, there's no file 
 called xacc-repdev.html. Is there an online version of this document 
 somewhere? I tried the CVS repository, but didn't have any luck there 
 either.

[From http://gnomesupport.org/wiki/index.php/GnuCashUsing ...]

Update (2004-04-25): The file xacc-repdev.html is part of the 
 GnuCash 1.6 documentation, which is no longer available or
 current.   You can find the file in the CVS Archive here [1].

[1]: 
http://cvs.gnucash.org/cgi-bin/cvsweb.cgi/gnucash/doc/sgml/C/Attic/xacc-repdev.sgml

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: QSF XML file backend for gnucash-gnome2-dev branch

[Josh Sled]

I wanted to echo Derek's comments: nice job!  :)

On Tue, 2005-01-25 at 11:38, Neil Williams wrote:

 I've got code in the patch just sent to gnucash-patches to correctly 
 distinguish a QSF XML file from v1, v2 or the older binary GnuCash text 
 formats and it loads using the QofBackendProvider mechanism rather than as a 
 GnuCash module.

A question came up on the IRC channel regarding this process... Can you
elaborate on how it's done?  Is the namespace [or lack thereof, in the
older XML case] of the file being opened used to branch on which backend
to use, or some other process?


 The patch includes the QSF schema for object and map files, it includes code 
 to install the schema in a qsf sub-directory of $prefix/share/ and it also 
 includes a test QSF map that will be the next phase of development to map 
 pilot-link QOF objects into GnuCash objects.

One problem I wanted to call out was the use of the URIs
urn:qof-qsf-map and urn:qof-qsf-container as the XML namespaces. 
Not only are they not registered URN namespace, but best practices are
to use a namespace-name which is generally resolveable [i.e., an
http-scheme URI], and which resolves into a useful document [i.e., is a
URL].

I'd recommend something date-stamped under http://qof.sourceforge.net/ 
... maybe: 

xmlns:qsfMap=http://qof.sourceforge.net/ns/qof/2005/01/qsf/map#;

xmlns:qsfContainer=http://qof.sourceforge.net/ns/qof/2005/01/qsf/container#;

... each of which is probably simply an HTTP redirect [303] back to the
documentation.


 The backend can cope with partial QofBooks and is designed to handle routines 
 that create a second QofSession, populate that session with data for export - 
 any QOF compatible objects - and save the session to export as QSF XML. There 
 is absolutely no requirement for AccountGroup or any other specific object to 
 be present, the backend will write out just invoices or just accounts, just 
 customers or any mix.

A better way to say this might be: it is the caller's responsibility to
ensure to the consistency, validity and coherence of the sub-set of data
being serialized.


 QSF increases the libxml2 requirement to 2.6.0 for the gnome2 branch to 
 support the schema validation which identifies QSF files relative to existing 
 files.

Is this the only reason for 2.6.0?

Can we make schematic validation optional?

Can we get rid of it entirely?


 QSF uses UTC time throughout and uses this time format string:
 #define QSF_XSD_TIME   %Y-%m-%dT%H:%M:%SZ
[deletia]
 The datestring must be timezone independent and include all specified fields.

To clarify:

* MUST the timezone be in UTC, or MAY it be in some non-UTC timezone, 
  as per [1]?
* If it MUST be, do you intend to fully support xsd:dateTime, or no?

[1] http://www.w3.org/TR/xmlschema-2/#dateTime


 as well as QOF_TYPE_DEBCRED as a QOF_TYPE_BOOLEAN currently. The parameter 
 will be converted back during the creation of the QofObject concerned.

Hmm.  I'm assuming debcred is actually an enumerated value; is the
intent to support that, or just to use boolean?

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: QSF XML file backend for gnucash-gnome2-dev branch

[Josh Sled]

On Tue, 2005-01-25 at 18:29, Neil Williams wrote:

 The existing methods are used to identify the existing data file types. If 
 those all fail, then I parse the document using one of the QSF schema and 
 proceed from there. That happens in gnc-backend-file.c, lines 390 onwards:

Got it; thanks.  That seems about right.


  One problem I wanted to call out was the use of the URIs
  urn:qof-qsf-map and urn:qof-qsf-container as the XML namespaces.
 
 I know. I'd appreciate any tips you have on registering a namespace, once a 
 suitable static URI is available - it's not yet.

To register a namespace:

Step 0: Make an http: URI.
[optionally] Step 1: Put valuable content at the end of the URI.

You can certainly use a URI before it's a URL.  If you're woried more
about long-term stability, then I recommend using a service like
http://purl.org/.


 I agree - this is a QOF backend and it will be used by pilot-link and 
 hopefully by other applications too - without GnuCash being installed. So it 
 would need to be somewhere on qof.sourceforge.net and only Linas has access - 
 I can't contact him, he hasn't been receiving email for a while.
 
 It still needs to be installed with QOF for offline purposes, as expected.

Well, there's no particluar requirement that it actually resolve to
anything, nor that the content at the end of the URL be used in the
parsing process.  It's just good practice that it resolve to
_something_, and at this point, preferrably a human-readable something.


  ... each of which is probably simply an HTTP redirect [303] back to the
  documentation.
 
 Which also isn't on sourceforge, it's on my own server. I wouldn't want that 
 to be the static URI, sourceforge is more likely to be sticking around!

Well, purl.org may be a bit-better-bet, then.  But, yes, sourceforge
would probably be quite good. 


   The backend can cope with partial QofBooks and is designed to handle
   routines that create a second QofSession, populate that session with data
   for export - any QOF compatible objects - and save the session to export
   as QSF XML. There is absolutely no requirement for AccountGroup or any
   other specific object to be present, the backend will write out just
   invoices or just accounts, just customers or any mix.
 
  A better way to say this might be: it is the caller's responsibility to
  ensure to the consistency, validity and coherence of the sub-set of data
  being serialized.
 
 Quite - QSF will never write an invalid XML file, nor accept one for input. I 
 was just waffling, as usual.

Well -- and please correct me if I'm wrong on this -- it sounds like one
can create a session which only contains only a subset of a
self-[referentially-]consistent object graph, and serialize that
fragment.  It would be valid XML, but semantically invalid because of
missing data...


  Can we make schematic validation optional?
 
 No. It's fundamental to how QSF accepts and parses the data. It's not just 
 schema validation that needs 2.5.2, there are some xml constructs that came 
 in at the same time.

Hmm.  I've written many XML parsers, and none _required_ a schema
definiton to parse data

It looks like you're doing the majority of the parsing as a side-effect
of the validation tree-traversal, but it doesn't seem like you
specifically _need_ to... Can you just switch from doing this during a
validation step to doing it during a normal tree-walk?

 Besides, I thought you were in favour of valid XML?

It certainly must be valid!  Doesn't necessarily need to be
_validated_,  however.  I.e., we don't need to compare the output XML to
some XML Schema definition [let alone a more reasonable
schema-definition language].

 I'd hate to write a DTD for this, the objects may be possible but the maps 
 are 
 quite something else.

I'd rather see a shift toward RelaxNG than toward DTD.

 No. Although the code will handle it, the XML will not validate. IIRC, the 
 -0500 format won't validate, it would need to be -05:00. Try it with xmllint 

Yeah, -0500 is wrong, as per xsd:dateTime.

 It's a nice idea but when you get up close with xmllint, you can't format the 
 timezone to validate without using regexps. It's easier to use UTC and Z.

Without using regexps where?

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

goffice/gog in g2 branch, new deps coming soon

[Josh Sled]

I've been working on getting a hacked version of libgoffice working
within GnuCash for the Gnome Office Graphing [GOG] support.

It is basically self-contained in `gnucash/lib/goffice/`, and I've it
compiling and working to display basic pie charts in reports.  I'm
getting close to a point to commit the code, but wanted to outline some
new dependencies and changes.

The following is a short summary of the configure.in differences:

+ AC_CHECK_HEADERS(ieeefp.h ieee754.h)
+ AC_CHECK_FUNCS(finite random drand48 finite memmove mkdtemp uname times 
sysconf)
+ PKG_CHECK_MODULES(GSF, libgsf-1 = 1.8.0
+libgsf-gnome-1 = 1.8.0)
+ PKG_CHECK_MODULES(ART, libart-2.0 = 2.3.11)
+ PKG_CHECK_MODULES(PRINT, libgnomeprint-2.2 = 2.5.2)

Some of these may be able to be pared down; I've just copied these
literally from gnumeric.

Unfortunately, the libgnomeprint-2.2 dep is beyond base FC1, which
shipped with 2.4.0 [1]; I'll try to figure that out more about that in
the next few weeks.


Also, for the moment, I've had to disable -Werror to get it to compile;
this is due to three things:

1/ Warnings which are due to the dull scalpel I used for the 
   transplantation.
2/ Natural warnings in the compilation due to different coding 
   standards.
2b/ #warning directives used as TODOs in some of the files.

I'm intending to commit [to the gnome2 branch] tomorrow or Thursday, so
if there are any major objections, please speak out now.  I could be
easily convinced to wait until the integration is in a better place
before committing, but frankly would like to get a checkpoint in CVS.

Also, FTR, I'll be out in CA next week, so I'll be a bit unresponsive to
problems encountered then; if you're very concerned about being blocked
on the gnome2 branch next week, I'd appreciate your trying the changes
out this weekend.

...jsled

[1] http://download.fedoralegacy.org/fedora/1/os/i386/

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: QSF XML file backend for gnucash-gnome2-dev branch

[Josh Sled]

On Wed, 2005-01-26 at 03:58, Neil Williams wrote:

 All applications using QSF would have their own user editable maps to convert 
 data to other applications. The maps are the real inter-operability stuff. 
 Application maps come with the installation, user edited maps can go with the 
 user edited objects - it's just a case of coding how the library expects the 
 application to 'go fetch'.

I don't quite understand the user edited maps.  I can see user-edited
data values, but the applicationA-applicationB maps don't seem like
user-edited content per-se...?

But, yeah, you're basically trying to do a [meta-]application task as a
library.  I'd be very thoughtful about the interface that the library
both presents-to and expects-of the application for the purpose of user-
and map-file management ... or maybe better: break that piece of the
puzzle off into a stand-alone qsf-map-control-console app.


 QOF will do that - by putting the data in XML as a single lump of objects, 
 QOF 
 can query the QofBook read from that XML and do all kinds of SQL-like things. 

Sure.  And you can do that with XSLT/XQuery if the XML data is in the
application-domain, too ... and you can do RDQL/Sparql if the data is in
RDF ... and straight SQL if it's in a relational DB.

I really do understand what you're trying to do, and understand its
value.  I also think you're re-inventing a /very/ large wheel,
_especially_ with respect to the mapping stuff.  I mean, you've already
had to create a new mini-programming langauge in the map definition
format ... why not just use an existing high-level language?


 Yes, the code checks the schema when determining the file type, when 
 preparing 
 to load the file and then leaves it until a file is ready to write out - at 
 which point it checks the outgoing file against the schema too. That just 
 catches bad use of the API where the object parameter types don't really 

Well, I feel about validation like I do about assertions: great during
development and debugging, but bad during runtime.   Perhaps we can
arrange things so that if the compilation system has libxml2 =2.6.0 and
--enable-debug, then the validation is done.  Otherwise not.


   It's determining the filetype and validating the content that would
   require duplication of the schema *code* so that I know which tags will
   occur where.
 
  The parser should impliclity have that knowledge.
 
 Once the schema has been used to identify objects vs maps, yes.

That identification can very easily happen without the schema; it's just
a string-comparison against the fully-qualified name of the root element
of the document, as I said before.


 The schema itself, the xsd, doesn't. The code that handles the schema would - 
 if we went below libxml2 = 2.5.2

*shudder*  There's no need to re-write a validator.


 Without runtime schematic validation, I would have to implement a method of 
 reliably distinguishing between qsf objects and qsf maps, checking the 
 content of every parameter tag matches the expected definitions, check that 
 each object and each parameter tag has the required attributes . . . . e.g. 

You only need to look at the fully-qualified name of the root element;
you can safely assume the rest...


 I'd have to individually validate every incoming date string to check the xsd 
 format. Every boolean would have to be checked and converted to TRUE instead 
 of true or 1 or T.

Overkill.  If the document claims via the name of it's root element that
it conforms to a schema and actually does not, then an error should be
raised during parsing.  Anyways, just because it's validated, you still
don't get to ignore parsing errors...  if you go to grab an expected
value  and it's not there, then you raise an exception.  If it's
optional, then you still have to check for that in the code.  If it's in
the wrong lexical format, then parsing errors should raise exceptions. 
If the lexical form of the data is valid but garbage, then the validator
won't determine that anyways.


 code the majority of the checks that the schema would have done. These QSF 
 objects are user-edited - all manner of garbage could be in them.

You expect these objects to be _user_ edited?  I thought the whole point
was machine-to-machine integration?  Import/Export stuff...

In any case, I would argue that it is the responsibility of the exporter
to generate correct XML.  If the exporter is a human-being, then an
editor which supports schema is useful, and publishing the schema in a
form that's readable for editors to understand and use is a good thing.


 I really can't do any of this without runtime schema validation. This is 
 quite 
 enough work as it is, re-inventing something that has ALREADY been released 
 is more than a little pointless.

It's not use existing vs. write your own, it's do it vs. don't do
it.  Very very few XML-parsing applications use runtime schematic
validation; I'm pretty sure that this doesn't need it either.


  By hand?  FTR, 

Re: QSF XML file backend for gnucash-gnome2-dev branch

[Josh Sled]

On Wed, 2005-01-26 at 13:22, Neil Williams wrote:

 I disagree, I prefer validation because there's no reason to implement a 
 sub-set of validation (just checking Doc-Root) when code exists to check the 
 whole. After all, you just said to use other existing methods rather than 
 implementing our own. Schema validation isn't our own, checking just the root 
 tag would be.

Apple: is this document what I expect to process via a string equality
check of the fully-qualified name of the root element.

Orange: re-implementing a validator.

You should still check the fully-qualified root element to see if you
should even _try_ to validate against the schema.


 I just don't feel that is sufficient. As the code is now operational, the 
 library version is satisfactory for the target and the schema is itself 
 useful for future development, I don't see any point in abandoning it further 
 down the road. If it wasn't working, I might agree with you.

I strongly believe the schema should be informative rather than used at
runtime, but I guess we'll just disagree on that; if validation is
working with a version of libxml2 that fits our platform-targeting, then
great.


 We all know XML will be edited when the needs arises, all we do is discourage 
 people from tampering with the complicated bits, like the map calculation. 

I wasn't talking about one-off debugging cases which expect looking
under the covers; it sounded earlier like your expected use-case was
hand-editing object data.  But I better understand your intent, now.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: goffice/gog in g2 branch, new deps coming soon

[Josh Sled]

On Tue, 2005-01-25 at 23:50, Derek Atkins wrote:

 2) I'm not sure what mkdtemp is.  I don't see that on Solaris,
so that could be a real problem.

Well, it's not listed in the lib/goffice/*.c files, so it's probably
spurious.

 3) Solaris also does not have ieee754.h

Hmm.  IIRC, a lot of the numeric/math deps are due to recent gnumeric
code in coordination with the R project ... importing their
well-tested/c. math routines.  It's unclear if GOG has a real
dependency on them, and thus on ieee754.h.  More digging required.

  + PKG_CHECK_MODULES(GSF, libgsf-1 = 1.8.0
  +libgsf-gnome-1 = 1.8.0)
 
 These are a problem.  RHEL3 only has 1.6.0.

GSF may be able to be a non-dependency; there are GSF-type-definition
macros all over the place, but very little actual usage.   Of course,
gnumeric-CVS actually has deps on libgsf-1.10.0, so the story may be
even worse.

  + PKG_CHECK_MODULES(ART, libart-2.0 = 2.3.11)
 
 I presume this is libart_lgpl-2.3.11-2?  If so then this should be
 fine w.r.t RHEL3.

Yes it is.  Good.

 This is also a problem; RHEL's libgnomeprint22 is only at 2.2.1.3.

Hmm.  This could be quite unfortunate, if the more recent version is
because of deps for printing graphs; again: more digging required.

Thanks for the info.

Are we cl


As per our discussion on IRC earlier, I'm going to commit this effort
this evening to a sub-branch of the gnucash-gnome2-dev branch called
'g2-gog-integ'; the branch and a branch-point tag called
'g2-gog-integ-bp' exist of about 10 minutes ago.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [RFC] A differnt options system

[Josh Sled]

I'm jumping into this thread late, since I had RealJob to do this
afternoon.  My summarized take after catching up on it all:

1/ We're all in agreement that the current options stuff is
less-than-optimal, to various degrees.

2/ Your proposal doesn't have feature-parity with the existing system,
which is a problem.  I believe that when it does, it'll have similar
complexity to the existing options stuff.


Specifically, I think there are 3 distinct facets to the options stuff
in discussion:

1/ option-type declaration
   a/ Enumerated types
2/ option-editing dialog building and runtime
3/ option-value persistance

Your proposal relates to these in the following way:

1/ the mapping between types and widgets is in the code
   a/ ??nothing -- since it's in C, nothing needs to be done, which is 
 false.??
2/ half-defer to glade/gtk; cut-and-paste
3/ not handled

As well, there's a partially-mentioned aspect that I personally have a
problem with, which is that the option db is generated scheme code
which is then eval'ed at startup, rather than simply being the raw
_data_ that it is.



I think the way to clean this stuff up is:

1/ flip the authority of the option-db implementation from scheme to 
   C. [It's probably best to do this after moving away from g-wrap, so 
   we don't need to change it again, but whatever...]

2/ clean up the API; phrasing, language, consistency, size and 
   documentation.

3/ clean up the option-value persistance and loading so it's less 
   weird, less dependent on scheme; use gconf and in-backend data where 
   appropriate [as opposed to book-parallel configuration storage].

4/ have better option layout support, via some declarative/gui-building 
   language.

5/ document how to do things like add a type, deal with sections, get 
   specific layouts, ...


I (and Derek) are totally sympathetic to the complexity.  But I don't
see how your proposal works within the existing code to make things
significantly better.



FTR, this is _always_ the rub with gnucash development, generally ...
there's a bunch of things exactly like this.  My mental cycle each time
is fsck it!  nuke it and start over ... oh, wait ... there's years of
work that would need to be re-written, and can't really be salvaged.   

We need to /evolve/ our way out of this mess.  In some places that's
more true than others ... I think the register should simply be
re-written, for instance.  But the options stuff is a bit too core for
that treatment, and I don't think it's warranted.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [RFC] A differnt options system

[Josh Sled]

On Wed, 2005-02-16 at 20:24, Derek Atkins wrote:

 scheme sort of has this dichotomy that merges the concept of code and
 data.  It's sorta the nature of the beast.  *shrugs*

Yah yah, I'm well aware of that... the problem, though, is that that
flexibility comes with a price.  Since the configuration is _anything_
you can never make simplifying assumptions about it.  E.g., setting a
boolean configuration option could end up doing a distributed
transaction across a set of resources spread across the wider
internet... or maybe it'll just invoke `(lambda () (quit))`.   Which
makes no sense.

Or not.  It's only the nature of the beast because our
option-data-format is eval'ed lambdas instead of simply data.

In code, it's useful to have code be data.
In data, it's useful to have data _not_ be code.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Wiki-FAQ

[Josh Sled]

On Thu, 2005-03-03 at 20:21, David Harrison wrote:

 I did a little bit of fooling around at
 http://gnomesupport.org/wiki/index.php/GnuCashFaq
 
 Ignoring content for now, as I just cut and pasted, is that the
 general layout that you had in mind.  

Yes.  That is awesome.

Thanks!

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: pango_layout_set_text

[Josh Sled]

On Wed, 2005-03-02 at 05:36, Neil Williams wrote:

 To me, it seems that we are passing a const char * to pango_layout_set_text() 
 when it is expecting a UTF-8 wchar_t wide char string.

Actually, I think that's slightly wrong.  pango wants UTF-8 strings,
which conveniently fit into char* ... since the whole point of UTF-8 was
to traffic ASCII unmodified and everything else within ASCII [via
escaped multi-character sequences].

The wchar_t types are a different, 32-bits-per-character [!] type that I
believe is UCS-4 encoding.

I'm almost positive we want UTF-8.

 Is this a character set issue (i.e. am I the only one seeing this) or should 
 these functions be converting const char to const wchar_t* using the C 
 library before calling pango?

Hmm.  I'm not sure where this is creeping in.  I'm definitely not seeing
the warnings, so it may be something on your side or in non-US locale
[which I should have but didn't check yesterday].

I've not looked, but I imagine libxml/xml-parsing should return UTF-8,
char* strings; we may need to set some settings to ensure this. 
GTK/Pango should traffic in UTF-8 char* strings.  Since those
[data-file, user-interface] are the two main ways to get data into
memory, that should cover our bases.

Do you see the issues on new-file-creation?

Can you isolate the source of the strings?

Certainly both US and English date strings should be ASCII-only.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: pango_layout_set_text

[Josh Sled]

On Tue, 2005-03-15 at 08:07, Neil Williams wrote:
 On Monday 14 March 2005 2:09 pm, Josh Sled wrote:
  Can you isolate the source of the strings?
 
 In a related problem, when I use the en_GB locale, Open Recent produces a 
 very 
 confusing (unusable) list. I've taken this from a screenshot:
 1 /opt/temp/business.gnc

Hmm.  For me, it only has the 1st entry, and the other lines are blank.

It also seems to randomly open a recently-opened file, rather than the
most-recently-openend.

*sigh*

I've added all 3 of these issues, plus the original
pango_layout_set_text / UTF-8 issue, to GNOME2_STATUS. :(

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: G2 branch doesn't build

[Josh Sled]

On Sun, 2005-04-03 at 04:08, Neil Williams wrote:

 Thereagain, until now I didn't now that GnuCash wasn't intended to use 2.4!
 :-)

Yeah, the only place this is in the source tree is ./configure.in [[[
# Look for libgnomeui by pkg-config
PKG_CHECK_MODULES(GNOME, libgnomeui-2.0 = 2.2
   gtk+-2.0 = 2.2)
]]].

  Builds on my FC3 system, but then that's gtk-2.4 based.  I'll fire up a
  compile on my vmware FC1 system and see how many problems there are.
 
 Thanks for doing that. It's good to know it was only this one choice that 
 caused a problem.

This has come up a couple/few times; specifically:

- what distros are we targeting?
- what's then the min(library_version) provided for our deps?

We should probably collect all that info into a file for reference. 
Since deps have, and will continue to be (given our desire to lag the
major distros by ~6 months), an important gnucash issue we should
probably have a README.dependencies or something.  The current
dependency list in README is from 2001.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: FreqSpec and SchedXaction as QOF objects

[Josh Sled]

On Sat, 2005-04-23 at 10:19, Neil Williams wrote:
 It's currently only GnuCash that puts limits on top level and sub objects and 
 it gets confusing sometimes. Certainly, within GnuCash there should not be 
 GncAddress or FreqSpec objects on their own - they simply won't get written 
 out by the normal backends. However, when QSF can deal with partial QofBooks 

Hmm.  There may be cases where GnuCash wants to have a run-time FreqSpec
that should not be persisted.  The scheduled transaction setup dialog,
for instance, internally uses a transient FreqSpec to maintain state. 

But the rest of your text sounds like that is fine; I just want to make
sure.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

G2 port completion threshold? [WAS: Re: FreqSpec and SchedXaction as QOF objects]

[Josh Sled]

On Sat, 2005-04-23 at 10:31, Derek Atkins wrote:
 Quoting Josh Sled [EMAIL PROTECTED]:
 
  Another option would be to help with the G2 port.  I've been
  anticipating doing the FS/SX QOFization next ... but _after_ the G2
  port is done.  Then the branching issues go away, we can get closer to
  release, c. :)
 
 That sort of begs the question, what does it mean for the G2 port to be 
 done?
 Personally I don't have a good answer for that, yet.

0/ Only gtk/gnome2 dependencies. :)

1/ G1 functionality parity; assuming that we keep track of this in 
   GNOME2_STATUS...

2/ GNOME2_STATUS list down to nothing/RFEs only (especially RFEs 
   for things that aren't related to G2 dependencies, like the 
   budgeting stuff or new iconage...)

3/ Some semblence of a coordinated effort to find more differences once 
   we belive that there are no more.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: FreqSpec and SchedXaction as QOF objects

[Josh Sled]

On Sat, 2005-04-23 at 09:44, Derek Atkins wrote:

 Also, when you make these changes you should make them to only HEAD
 __OR__ g2.  Pick one and stick with it.  David Hampton performs
 monthly (or so) merges from Head up to g2, and if you make the same
 set of changes in both branches it makes the merge significantly
 more difficult.
 
 Beyond all that, I have no problem with QOFizing FS and SX.

No problems here, either.

It needs to be done.  There's another set of changes around that that I
don't know if you're planning on ... the key one being making the SX
list (the UI bit) be the results of a QOF query rather than a trivial
glist field of the Book...?

Another option would be to help with the G2 port.  I've been
anticipating doing the FS/SX QOFization next ... but _after_ the G2
port is done.  Then the branching issues go away, we can get closer to
release, c. :)

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Hello world

[Josh Sled]

On Sat, 2005-04-23 at 14:32, Daniel Tudosie wrote:
 Ofcourse I would like to help in the effort of porting gnucash to gnome2

The best place to start here, apart from simply getting the code
checked out and built, is the GNOME2_STATUS file.  It contains the
canonical list of issues, differences and overall status of the
gnome2-porting effort.

Note that this file is only found on the 'gnucash-gnome2-dev' branch.

 mail-list) what development env. are you using ? (I am using gnome and I
 have installed Anjuta which I am not familiar with; but I am also a fan
 of gnu emacs) is there a dev tips and tricks section that I haven't
 found ?

Well, there's README, of course.  The HACKING file, but it's a bit
light...

In terms of development environment, I use emacs.

 For the rest of information (e.g. about specific libraries to be used in
 develpment) I will either search or ask.

Most of our dependencies are listed as checks in configure.in.  Given
our historical and overall dependency issues, we're definitely picky
about introducing new dependencies.

 So this is just a friendly Hello world message to the dev-list (a more
 friendly mail list I hope :-) ).

Certainly it is.  The current thread on -user is really atypical, FWIW.


On Sat, 2005-04-23 at 16:05, Daniel Tudosie wrote: 
 Well, for now I don't really know... I have compiled the
 gnucash-gnome2-dev branch onto my Ununtu system (distro based on Debian
 unstable - for those who do not know...) and I will look into the code,
 as I liked how it looks but also noticed that not all reports work

Hmm.  Most of the HTML/table portions of the reports should work just
fine. Charting and graphing is a known problem; see GNOME2_STATUS for
more details.  There is a sub-branch for the GOG integration, though
there are some more recent developments (like earlier this week) not
really reflected anywhere. :/

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Newbie: how to launch gnucash built from source ?

[Josh Sled]

On Fri, 2005-04-29 at 06:01, Geert Janssens wrote:
 So it uses /usr/lib instead of /opt
 
 How can I have it start the build installed in /opt ?
 
 This seems like a trivial thing to do, but I can't figure it out... blush

That's odd.  How did you build it?  I.e., what arguments did you give
when running `./autogen.sh`?

I usually do:

./autogen.sh --prefix /opt/gnc-g2-unstable --enable-debug --enable-etags
--enable-doxygen  make install

When I then do `/opt/gnc-g2-unstable/bin/gnucash`, it definitely runs
the /opt -installed version.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Newbie: how to launch gnucash built from source ?

[Josh Sled]

On Fri, 2005-04-29 at 09:50, Geert Janssens wrote:
 Since your reply suggests it should, I have removed everthing, and started 
 from scratch, this time avoiding the very first attempt (the one without 
 parameters to autogen.sh, and using DESTDIR). Gnucash starts just fine now 
 (indicating CVS version), so I suspect the DESTDIR construct caused something 
 to get poorly configured.

Ah, that is too bad that the first DESTDIR attempt seems to have
effected changes that render future, correct attempts broken... :/

In any case, I'm glad you're up and running, now.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel