Re: speed?

[Dave Peticolas]

> > > 
> > > I think the bottleneck is in the Gnome Canvas, which is the basis of
> > > the register display.  Dave P would know more about that.
> > 
> > I suspect this is where it's happening, but we will need to do some
> > profiling to be sure.
> 
> Is each entry field in the register a separate Gnome widget?

No, there is one widget which gets moved around as needed.


> Do you suppose that the canvas does its complete set of layout calculations
> over again when a transaction is deleted?  Or entered? Or changed?
> Would it be useful if I looked into the Gnome source code about this?

I'm not too familiar with the details of the canvas's operation and its
use in GnuCash; Heath Martin will know more. Source code inspection is
always useful, I think :) You will also want to look in src/register
and src/register/gnome.

 
> Do you happen to know what profiling tools I should look for under
> Linux? Every OS I've used has a different way of doing this, and the best
> one is usually discovered by word-of-mouth, not by looking in manuals.

The only one I know of under linux is gprof, which has a nice set of
info pages. To use it, you will need to compile gnucash with profiling
enabled. You can do that by running configure with the --enable-profile
argument. You will need to run make clean so that all object files get
recreated.


> By the way, is there a maximum allowable size to the memo field, cheque
> number field, etc? (I don't care if there are current limits on how much
> is displayed (these are at worst temporary(and they resize with the window
> (Aha! Four nested parentheses in an English prose. Natural language
> catches up to Lisp))), as long as all the data get
> into the file.)

The length of the string must fit in an integer, but other than that
there are no limits.

dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: speed?

[Rob Walker]

> On Fri, 2 Jun 2000 22:37:30 -0400 (EDT), Hendrik Boom
> <[EMAIL PROTECTED]> said:

Hendrik> By the way, is there a maximum allowable size to the memo
Hendrik> field, cheque number field, etc? (I don't care if there are
Hendrik> current limits on how much is displayed (these are at worst
Hendrik> temporary(and they resize with the window (Aha! Four nested
Hendrik> parentheses in an English prose. Natural language catches up
Hendrik> to Lisp))), as long as all the data get into the file.)


I hope that you use emacs to edit that paragraph, so you knew hw to
close the parens.

rob

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: importing one-ended transfers

[Richard Wackerbarth]

On Fri, 02 Jun 2000, Hendrik Boom wrote:
> > On Wed, 31 May 2000, Hendrik Boom wrote:
> > > I now see the following possibility:
> > >
> > > One transaction, that
> > >   debits the chequing account by $200, memo groceries
> > >   debits the chequing account $10, memo cash
> > >   debits the chequing account $90, memo allowances
> > >   credits the allowance account $90,
> > >   credits the cash account $210
> > >
> > > This way the Quicken splits become gnucash splits in the same accounts.
> > > And Quicken splits that are associated with a category end up
> > > associated with the appropriate account.
> >
> > I'm not sure that I follow your logic here. Look at it from another view:
> >
> > Credit Allowance $ 90
> > Debit  Chequing  $300
> > Credit Cash  $200 groceries
> > Credit Cash  $ 10 cash
>
> except that you lose the memo "allowances".

Sorry, that is just a "typo" error. That memo should be attached to the first 
line.
>
> > This seems to me to be closer to the transaction items that you would
> > actually realize.
>
> I'd be just as happy with your version as mine.
> It's just that I don't clearly see how your version generalises to
> situations where both ends of the transaction have been split in Quicken.

I had to "jump through hoops" to create such transactions in Quicken.
And the QIF form of them is virtually unrecognizable.

However, I acknowledge that we need to have transactions in gnucash that have 
multiple JEs for the same account.
This was discussed on this list a few weeks ago.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: importing one-ended transfers

[Hendrik Boom]

> On Wed, 31 May 2000, Hendrik Boom wrote:
> > I now see the following possibility:
> >
> > One transaction, that
> > debits the chequing account by $200, memo groceries
> > debits the chequing account $10, memo cash
> > debits the chequing account $90, memo allowances
> > credits the allowance account $90,
> > credits the cash account $210
> >
> > This way the Quicken splits become gnucash splits in the same accounts.
> > And Quicken splits that are associated with a category end up associated
> > with the appropriate account.
> 
> I'm not sure that I follow your logic here. Look at it from another view:
> 
> Credit Allowance $ 90
> Debit  Chequing  $300
> Credit Cash  $200 groceries
> Credit Cash  $ 10 cash

except that you lose the memo "allowances".

> 
> This seems to me to be closer to the transaction items that you would 
> actually realize.

I'd be just as happy with your version as mine.
It's just that I don't clearly see how your version generalises to situations
where both ends of the transaction have been split in Quicken.

> 
> I suspect that the bank only knows that you withdrew $300.
> >From an accounting view, you have chosen to credit part of that to the 
> Allowance account and the rest to the Cash account. You are using the memo 
> field to represent subaccounts Cash:Groceries and Cash:Petty_Cash.
> 
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
> 
> 


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: speed?

[Hendrik Boom]

> > 
> > I think the bottleneck is in the Gnome Canvas, which is the basis of
> > the register display.  Dave P would know more about that.
> 
> I suspect this is where it's happening, but we will need to do some
> profiling to be sure.

Is each entry field in the register a separate Gnome widget?
Do you suppose that the canvas does its complete set of layout calculations
over again when a transaction is deleted?  Or entered? Or changed?
Would it be useful if I looked into the Gnome source code about this?

Do you happen to know what profiling tools I should look for under
Linux? Every OS I've used has a different way of doing this, and the best
one is usually discovered by word-of-mouth, not by looking in manuals.

By the way, is there a maximum allowable size to the memo field, cheque
number field, etc? (I don't care if there are current limits on how much
is displayed (these are at worst temporary(and they resize with the window
(Aha! Four nested parentheses in an English prose. Natural language
catches up to Lisp))), as long as all the data get
into the file.)


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: Data type problems & solutions

[Christopher Browne]

On Thu, 01 Jun 2000 13:14:39 CDT, the world broke into rejoicing as
John Goerzen <[EMAIL PROTECTED]>  said:
> I have been doing some investigation to figure out why gnucash is working on
> my i386 but getting confused on the alpha.
> 
> I have come up with a few findings.  I guess I may be the first
> one trying to use it on a 64-bit platform so I will try to send y'all some
> patches ASAP.
> 
> Anyway, the code seems to incorrectly assume that:
> 
>  * a long is 4 bytes.  On Alpha, it's 8.
>  * a long is different than a long long.  On Alpha, it's not.
>  * a long is the same as an int.
> 
> Anyway, the offendor I have noted here is this.  Here is code in
> writeTSDate:
> 
>   tmp = ts->tv_nsec;
>   XACC_FLIP_INT (tmp);
>   err = write( fd, &tmp, sizeof(int) );
> 
> But look at the corresponding code in readTSDate:
> 
>   err = read( fd, &nsecs, sizeof(long int) );
> 
> Now...  on i386, this will work.  Why?  Because both int and long are 32-bit
> on i386.  On Alpha, int is 32-bit and long is 64-bit.  So, the code writes a
> 4-byte int and tries to read it back as an 8-byte int.  Oops.
> 
> If the binary format is going to be preserved, I would *highly* recommend
> that at least abolish the usage of int, long, and long long in the code (or
> at least the stuff that does file I/O) and instead use macros or typedefs
> that explicitly specify the size such that it can be correct on all archs.
> 
> I note that Debian includes a stdint.h file with the following macros:
> 
> uint8_t
> uint16_t
> uint32_t
> uint64_t
> int8_t
> int16_t
> int32_t
> int64_t
> 
> What I don't know is how standard stdint.h is, so ports to non-GNU
> architectures may not be as easy.  However, I suspect that autoconf may have
> something available here.
> 
> I shall go through the file today and make these changes, and let you know
> if it fixes my problems.  If it does, I'll send a patch along.  Is this
> mailing list used for patches?  If not, to what address should they be sent?
> 
> Alternatively, if there is a newer version in CVS or somewhere, you may want
> to patch it yourself (a well-thought-out search & replace should do the
> trick), in case there are new places to patch.
> 
> Normally I might suggest just fixing this one case.  But again, with data as
> important as that which is handled by gnucash, I feel that there is zero
> room for error and explicitly stating the sizes can go a long way to
> improving portability.
> 
> Finally, sorry for barraging the mailing list with all these messages :-)
> I just tried gnucash yesterday, and was instantly hooked on it.  Y'all are
> doing a great job, and thanks for a great program!

No big problem; I would, by the way, suggest that you look to 
/usr/include/glib.h rather than anywhere else.

GnuCash _does_ have a forcible dependancy on glib, so that depending on
the "force-a-particular-width" typedefs in /usr/include/glib.h does not
add any additional dependancies to GnuCash as a whole.

I'd tend to think it a good idea to go through the code base and 
introduce rather a lot of "gint32" values throughout...
--
[EMAIL PROTECTED] - 
"Optimization hinders evolution."  -- Alan Perlis

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: speed?

[Hendrik Boom]

> 
> Another topic: what sorts of duplicate transactions are you finding
> after QIF import?  IIRC you have mentioned two classes of problem: one
> is the Opening Balance in non-first-position and one is Quicken
> collapsing two splits into one.  Are there other types of problem
> transactions you have identified?

No. The ones I have identified in the last few days are the only ones
I have encountered.

>  
> > My guesses (using psychic debugging, without reference to source code)
> > is:
> > ...
> 
> These two are not right.  There's no Guile code involved in the
> register display at all, that I know of, and certainly not in the
> actual display-construction.

Well, my reputation as a psychic has always been dismal. ;-)

> 
> > P.S. For what it's worth, my processor is a Pentium running at 39.73
> > BogoMIPS; 48 meg of RAM.  I'm running SuSE Linux 6.3.
> 
> Well, that's hardware that would kindly be called "pathetic" these
> days :), but I think gnucash should be able to run fine on it.  If it
> doesn't, that's something we need to work on.

So far, it's fine for everything I really need except video games.
We have a nearly-dedicated Windows 95 machine for that.  It's not supposed
to have any sensitive or critical data on it; hence the desire to move
from Quicken there to gnucash here.

> 
> Bill Gribble
> 
-- hendrik.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: g-wrapping enums (was Re: Reporting subsystem and other stuff)

[Robert Graham Merkel]

Rob Browning writes:
 > Robert Graham Merkel <[EMAIL PROTECTED]> writes:
 > 
 > > My suggestions would be to have something like g-scan which can scan
 > > a header file, locate marked enumerations, and generate the
 > > necessary C and Scheme code to automate the type conversion, as well
 > > as allow C functions that take that type to be wrapped.  We would
 > > also generate some Scheme that converts between a symbolic and
 > > numeric representation.  Writing the parser might be a pain, but
 > > provided we don't try anything too tricky (like use the preprocessor
 > > inside enumeration declarations) it should work.
 > 
 > As far as I'm concerned, scanning headers (or C code at all) is a bad
 > idea.  I've been down that road before, and unless you're willing to
 > write a full C preprocesor/parser and track the C language carefully,
 > you're bound to leave yourself open to messes you're better off not
 > expending your effort on.

OK, point taken.

 > So I'd be much happier seeing g-wrap either:
 > 
 >   1) allow you to define a C side function that handles the
 >  translations from the C enums to ints, and g-wrap can call that
 >  at startup to load a table.  This would require you to keep that
 >  function up to date as you modify the enumeration, but that's not
 >  that much effort, and it would require you to include calls in
 >  your guile side code to lookup the integer values when you need
 >  them.
 >

So what does this actually buy you, as composed to wrapping the type
manually?  From my understanding of g-wrap, not all that much.


 >   2) allow, for people who really want things automated and are
 >  willing to accomodate g-wrap, the user to describe the
 >  enumeration(s) in a simple spec file.  gwrap would then use this
 >  spec file to generate both the guile side code *and* an
 >  appropriate C header snippet.  This could be #included wherever
 >  desired.  This approach keeps us from having to parse C, and it
 >  makes it impossible to have skew between the g-wrap and C
sides.

I do kind of prefer this.  The down side is that it means that enums
get taken out of header files, but you can generate *all* the code
needed to deal with enumerations.

However, is the pain of having a seperate spec file worth it?  In 
a lot of cases, I think so.  src/engine/query.h is probably a good
example of where having a fully automated system would probably be
rather worthwhile.

-- 

Robert Merkel  [EMAIL PROTECTED]



--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: Problem with transfers/double accounting

[Bill Gribble]

tboldt <[EMAIL PROTECTED]> writes:
> I think you are probably right in your assesment of double
> entry/single entry - however - and there is an however, How many
> non-professionals do you know that think in terms of double entry
> accounting??

This is a straw man.  There are lots of people using gnucash right now
with no problems and I doubt there are more than 5 people on this list
who could even vaguely be considered to be financial professionals.

Double entry bookkeeping is just not that hard.  Yes, there is a
learning curve, but there's a learning curve with EVERY piece of
software.  Given good documentation and tutorial instruction, someone
who wants to use the software will be able to figure out how.

> Again, I say who is your targeted primary user - the professional,
> semi-professional or the converted Quicken user?
> 
> Can you satisfy all three? Should you satisfy all three?  Will you
> come up with the proverbial camel - a horse designed by a committee
> - if you try to satisfy all three?

It's just not all that interesting to talk about the problems that
hypothetical "average" users will have, when you keep insisting that
"average" users are too stupid to understand double entry.

I don't mean to dismiss your criticism, but you are just repeating the
same thing over and over, and it smells more and more like FUD.  Do
YOU PERSONALLY have problems understanding what gnucash is doing?  If
so, ask questions and we'll try to answer them.

It's a basic premise of gnucash that people are NOT too stupid to
understand double entry, and in fact that programs like Quicken
cripple people's abilities to store and analyze their financial
information by restricting them to an artificially simplistic model.
I think it would be wrong to try to replicate that "feature".

Bill Gribble

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: check_printing_bug

[Bill Gribble]

David Bobroff <[EMAIL PROTECTED]> writes:
> Check printing appeared to be working finally.  It had not been working for
> me and then suddenly it was working.  

The check printing code that's in CVS right now is outdated, and while
I haven't seen symptoms like you describe, I don't doubt that it's
incompatibilities with the most recent gnome-print libraries.

Check printing will be disabled within the next few days and will show
up shiny and new as soon as the new gnucash-1.5 development series
starts.  

Bill Gribble

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: speed?

[Dave Peticolas]

> Hendrik Boom <[EMAIL PROTECTED]> writes:
> > Is there a speed problem, or am I doing something wrong.?
> 
> For large numbers of transactions, the current register code doesn't
> exactly set speed records.  I only have 2000 or so transactions in my
> largest accounts, and the speed could be better, even though I'm on a
> fast machine.  I agree that it's something that needs to be addressed.
> 
> I think the bottleneck is in the Gnome Canvas, which is the basis of
> the register display.  Dave P would know more about that.

I suspect this is where it's happening, but we will need to do some
profiling to be sure.

dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: GnuCash Wish List

[Dave Peticolas]

> > 
> > 1) A warning if you are running it as root, or even better if it is unsucce
> ssful in saving your file (this comes from one day accidentally putting in ab
> out an hour of figures, hitting save and going back the next day to find that
>  it hadn't actually saved anything because the time before I accidentally ran
>  it as root and thus the file was now read-only).

Yes, this is a bad one. I will try to fix this for 1.4.


> > 2) During balancing, the ability to change the starting balance. I imported
>  accounts from another app, which of course had a balance.. but when I went t
> o reconcile them later GnuCash insisted that the opening balance be "$0.00".

The starting balance for the reconciled window is the balance of all the
previously reconciled transactions. Since none of the transactions have
been reconciled, the starting balance is zero.


> > 3) The ability to switch the order of the fields on the register page. Not 
> a big deal, but in other applications, and in fact in my actual checkbook, th
> e deposit and withdrawl fields are opposite of what they are in GnuCash.

This is on my todo list, but may have to wait until 1.5.


> > Thanks for listening, and again thank you for GnuCash :)

thanks for your feedback,
dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: Problem with transfers/double accounting

[tboldt]

Richard Wackerbarth wrote:

> On Fri, 02 Jun 2000, tboldt wrote:
> > Under this view I "transfer" funds and "move" transactions. For
> > example, I "transferred funds" from account A to account B using the
> > register window for account A. Later, I decide that account was the wrong
> > source of the funds and account C should be the proper source. To the
> > non-professional I would "move" the transaction from A to C and gnucash
> > should take care of resetting the proper "from" account. A professional
> > accountant would just think, if I get your argument right, okay I change
> > the "Transfer From" window to read C instead of A and gnucash then takes
> > care of "moving" the transaction from the A register to the C register.
>
> I think that your view is more that of "single entry"/"double entry" rather
> than "professional accountant"/"non-professional".
>
> In single entry, you imply the transfer from the account which the register
> represents. In that context, "moving" the transaction to another register
> makes sense. However, you seem quite willing to "edit" the expense category.
> In reality, that is "moving" the transaction to a different expense account.
>
> In double entry, we don't make the distinction between asset accounts and
> expense categories. They are both accounts. Therefore, editing any part of
> the transaction makes sense. Changing an account is just changing an account.

I think you are probably right in your assesment of double entry/single entry -
however - and there is an however, How many non-professionals do you know that
think in terms of double entry accounting?? Probably all of the professionals
do, maybe the small buisness owners do (after they have been small buisness
owners and have been "educated" by their accountants). The average Jane/Joe
working for a W2 probably doesn't know beans about double entry. Maybe after
using a program like gnucash for a few months/years they will. How many Quicken
users do you think really think in terms of double entry accounting? I have
never, ever used Quicken, I used CA Simply Money. Looking back after using
gnucash for a very short time, doing double entry under Simply Money was
probably doable, but not easily. I'll bet that Quicken is the same.

Again, I say who is your targeted primary user - the professional,
semi-professional or the converted Quicken user?

Can you satisfy all three? Should you satisfy all three?  Will you come up with
the proverbial camel - a horse designed by a committee - if you try to satisfy
all three? Only time will tell. But you should be diligently trying to answer
that question if haven't already.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

check_printing_bug

[David Bobroff]

Hello all,

Check printing appeared to be working finally.  It had not been working for
me and then suddenly it was working.  I'm not actually using it but I was
trying it out.  Now, however, when I select a transation and do 'print
check...' I get the dialog box with all of the options for date format etc.
but when I click "OK" Gnucash quits.

I am currently running Gnucash 1.3.8 as of cvs update announced by Dave
Peticolas as "cvs 2000-06-02" and time-stamped 12:13 pm.  I think I should
also add that I recently updated to Helix-Gnome 1.2 so it could be one or
the other (or some combination of the two).  I think this was also the
first time I tried the check printing since updating to Gnome 1.2.

Thanks,

David Bobroff
[EMAIL PROTECTED]

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: speed?

[Bill Gribble]

Hendrik Boom <[EMAIL PROTECTED]> writes:
> Is there a speed problem, or am I doing something wrong.?

For large numbers of transactions, the current register code doesn't
exactly set speed records.  I only have 2000 or so transactions in my
largest accounts, and the speed could be better, even though I'm on a
fast machine.  I agree that it's something that needs to be addressed.

I think the bottleneck is in the Gnome Canvas, which is the basis of
the register display.  Dave P would know more about that.

> I just imported *all* my Quicken accounts, and then started tracking
> down duplicated entries.

Another topic: what sorts of duplicate transactions are you finding
after QIF import?  IIRC you have mentioned two classes of problem: one
is the Opening Balance in non-first-position and one is Quicken
collapsing two splits into one.  Are there other types of problem
transactions you have identified?
 
> My guesses (using psychic debugging, without reference to source code)
> is:
> (a)
>   - because gtk+ imposes a scrolling area limit af 32K pixels, 
> you have too handle scrollong at a higher level in the protocol.
>   - the higher layer is written in guile, which is interpreted (like Java)
>   - so scrolling slows down quite a bit.
> (b)
>   - deleteing a transaction involves recalculating sizes for the entire
> scroling area, and this also is done in guile, is interpreted, and
> so each deletion might end up taking the same order of magnitude
> of time as some of the analysis activities during importing.

These two are not right.  There's no Guile code involved in the
register display at all, that I know of, and certainly not in the
actual display-construction.

> P.S. For what it's worth, my processor is a Pentium running at 39.73
> BogoMIPS; 48 meg of RAM.  I'm running SuSE Linux 6.3.

Well, that's hardware that would kindly be called "pathetic" these
days :), but I think gnucash should be able to run fine on it.  If it
doesn't, that's something we need to work on.

Bill Gribble


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: Problem with transfers/double accounting

[Dave Peticolas]

> On Fri, 02 Jun 2000, tboldt wrote:
> > Under this view I "transfer" funds and "move" transactions. For
> > example, I "transferred funds" from account A to account B using the
> > register window for account A. Later, I decide that account was the wrong
> > source of the funds and account C should be the proper source. To the
> > non-professional I would "move" the transaction from A to C and gnucash
> > should take care of resetting the proper "from" account. A professional
> > accountant would just think, if I get your argument right, okay I change
> > the "Transfer From" window to read C instead of A and gnucash then takes
> > care of "moving" the transaction from the A register to the C register.
> 
> I think that your view is more that of "single entry"/"double entry" rather 
> than "professional accountant"/"non-professional".
> 
> In single entry, you imply the transfer from the account which the register 
> represents. In that context, "moving" the transaction to another register 
> makes sense. However, you seem quite willing to "edit" the expense category.
> In reality, that is "moving" the transaction to a different expense account.
> 
> In double entry, we don't make the distinction between asset accounts and 
> expense categories. They are both accounts. Therefore, editing any part of 
> the transaction makes sense. Changing an account is just changing an account.

I think this issue will go away with the next release, where the
'blank transaction' will go back to using a 'transfer' account field
instead of the direct field. This makes sense for entry, as you are
going to enter a transaction for account A into the register for
account A.  Existing transactions will use the direct 'Account'
field.

dave


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: Problem with transfers/double accounting

[Richard Wackerbarth]

On Fri, 02 Jun 2000, tboldt wrote:
> Under this view I "transfer" funds and "move" transactions. For
> example, I "transferred funds" from account A to account B using the
> register window for account A. Later, I decide that account was the wrong
> source of the funds and account C should be the proper source. To the
> non-professional I would "move" the transaction from A to C and gnucash
> should take care of resetting the proper "from" account. A professional
> accountant would just think, if I get your argument right, okay I change
> the "Transfer From" window to read C instead of A and gnucash then takes
> care of "moving" the transaction from the A register to the C register.

I think that your view is more that of "single entry"/"double entry" rather 
than "professional accountant"/"non-professional".

In single entry, you imply the transfer from the account which the register 
represents. In that context, "moving" the transaction to another register 
makes sense. However, you seem quite willing to "edit" the expense category.
In reality, that is "moving" the transaction to a different expense account.

In double entry, we don't make the distinction between asset accounts and 
expense categories. They are both accounts. Therefore, editing any part of 
the transaction makes sense. Changing an account is just changing an account.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: Problem with transfers/double accounting

[tboldt]

Richard Wackerbarth wrote:

> On Thu, 01 Jun 2000, Bill Gribble wrote:
> > tboldt <[EMAIL PROTECTED]> writes:
> > > I would have to agree - having the ability to transfer a transaction from
> > > one account to another using a field in the transaction entry is going to
> > > be very confusing. You are mixing entry fields for the transaction with
> > > actions done to the transaction.
> >
> > Actually, no.  The account on "this end" of the transaction is as much
> > of a data field of the transaction as the account on "that end".  It
> > makes sense to be able to change either end from a register view of
> > the transaction, just as you could change the "Transfer From" field
> > for a split.
>
> I think that the problem is that the users tend to think of transactions as
> being associated with accounts. In reality, they are not intrinsically
> associated with any account.
>
> The register is just a report that uses the transactions which happen to
> affect that particular account. However, when you edit any transaction, you
> are not doing so in the context of an account. The edit of a transaction
> could just as well be done in its own separate window.
>
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]

I guess this comes down to who is your intended user:

 1) professional accountants who view transactions divorced from accounts and
thus would have no problem with "moving" transactions from one account to
another since they aren't really moved. The transaction cannot be "moved" if it
was never really "in an account" in the first place. Under this view, which I
have a hard time understanding - I compare this to learning OO programming after
too many years in non-OO programming, the terms "moving the transaction" and
"transferring funds", I guess, would tend to meld into the same thing. Thus,
using what I call a data entry field for this purpose makes sense - I guess.

2) non-professionals who want more than a checkbook register. These people would
tend to view transactions as associated with an account. These types would tend
to view the register windows as data entry windows into which they enter data
into "an account" or "transfer funds from one account to another". Under this
view I "transfer" funds and "move" transactions. For example, I "transferred
funds" from account A to account B using the register window for account A.
Later, I decide that account was the wrong source of the funds and account C
should be the proper source. To the non-professional I would "move" the
transaction from A to C and gnucash should take care of resetting the proper
"from" account. A professional accountant would just think, if I get your
argument right, okay I change the "Transfer From" window to read C instead of A
and gnucash then takes care of "moving" the transaction from the A register to
the C register.

I guess that viewed in that manner, both arguments are "right" - which do you
think non-professionals will think of first and which do you think the
professionals will think of first and which do you want as your primary users?
Can you satisfy both - I really don't know.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

cvs 2000-06-02

[Dave Peticolas]

CVS has been updated.

New Stuff:

 + Dennis Bjorklund's sv.po update

 + Paul Fenwick's Quote.pm update

 + Jan-Uwe Finck's updated de.po


dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

speed?

[Hendrik Boom]

I'm slowly gearing up to use GnuCash on live data, and am attempting
to start parallel operation with Quicken before cutting over comletely.
As a result I am continuing to find problems, some of which are relatively
easy to fix.

But some, I suspect are not.

Is there a speed problem, or am I doing something wrong.?

I just imported *all* my Quicken accounts, and then started tracking
down duplicated entries.

Once I find one, it takes 45 seconds to delete it, starting from the
moment I confirm the deletion to the moment the register has its
new contents.  This is the performance I expect from Java.

I also notice that scrolling is quite slow.

Also, if I happen to move the delete-confirmation window by grabbing it
by its title bar, the window leaves a trail of ghosts, which slowly disappear
at the rate of about one per second.

The account I am editing has something like 7000 or so transactions.
Could this be relevant?

My guesses (using psychic debugging, without reference to source code)
is:
(a)
  - because gtk+ imposes a scrolling area limit af 32K pixels, 
you have too handle scrollong at a higher level in the protocol.
  - the higher layer is written in guile, which is interpreted (like Java)
  - so scrolling slows down quite a bit.
(b)
  - deleteing a transaction involves recalculating sizes for the entire
scroling area, and this also is done in guile, is interpreted, and
so each deletion might end up taking the same order of magnitude
of time as some of the analysis activities during importing.
(c)
  - Events are queued, and not subsumed.  So if you press the up cursor
three times in a row, you end up displaying the register in three
separate positions, instead of counting up-cursor presses and moving
the register three lines all at once.

I don't know if these analyses are correct, or whether the problems are
in gnome/gtk+ or in the guile code for gnucash.  In any case, this is
probably not something to try and fix before the 1.4 code freeze.
And perhaps the proper fix would be in gnome, not gnucash.

Any comments?

-- hendrik.

P.S. For what it's worth, my processor is a Pentium running at 39.73 BogoMIPS;
48 meg of RAM.  I'm running SuSE Linux 6.3.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: Problem with transfers/double accounting

[Richard Wackerbarth]

On Thu, 01 Jun 2000, Bill Gribble wrote:
> tboldt <[EMAIL PROTECTED]> writes:
> > I would have to agree - having the ability to transfer a transaction from
> > one account to another using a field in the transaction entry is going to
> > be very confusing. You are mixing entry fields for the transaction with
> > actions done to the transaction.
>
> Actually, no.  The account on "this end" of the transaction is as much
> of a data field of the transaction as the account on "that end".  It
> makes sense to be able to change either end from a register view of
> the transaction, just as you could change the "Transfer From" field
> for a split.

I think that the problem is that the users tend to think of transactions as 
being associated with accounts. In reality, they are not intrinsically 
associated with any account.

The register is just a report that uses the transactions which happen to 
affect that particular account. However, when you edit any transaction, you 
are not doing so in the context of an account. The edit of a transaction 
could just as well be done in its own separate window.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: importing one-ended transfers

[Richard Wackerbarth]

On Wed, 31 May 2000, Hendrik Boom wrote:
> I now see the following possibility:
>
> One transaction, that
>   debits the chequing account by $200, memo groceries
>   debits the chequing account $10, memo cash
>   debits the chequing account $90, memo allowances
>   credits the allowance account $90,
>   credits the cash account $210
>
> This way the Quicken splits become gnucash splits in the same accounts.
> And Quicken splits that are associated with a category end up associated
> with the appropriate account.

I'm not sure that I follow your logic here. Look at it from another view:

Credit Allowance $ 90
Debit  Chequing  $300
Credit Cash  $200 groceries
Credit Cash  $ 10 cash

This seems to me to be closer to the transaction items that you would 
actually realize.

I suspect that the bank only knows that you withdrew $300.
>From an accounting view, you have chosen to credit part of that to the 
Allowance account and the rest to the Cash account. You are using the memo 
field to represent subaccounts Cash:Groceries and Cash:Petty_Cash.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Is gnucash.org down?

[Allan Peak]

I've been unsuccessfully trying to get to gnucash.org
for several days to D/L the latest and greatest.

__
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

cvs 2000-06-02

[Dave Peticolas]

CVS has been updated.

New Stuff:

 + Rob Browning's automake patch. This patch makes gnucash use
   automake for its build system. Among other things, this should
   make gnucash much more portable. Also, there is now a 'make uninstall'
   target.

   WARNING: this patch seems to break the gnc-prices script.


dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: GnuCash Wish List

[linas]

FYI,

It's been rumoured that Steven Sforza said:
> 
[...]
> Among the things I'd love to see are:
> 
> 1) A warning if you are running it as root, or even better if it is unsuccessful in 
>saving your file (this comes from one day accidentally putting in about an hour of 
>figures, hitting save and going back the next day to find that it hadn't actually 
>saved anything because the time before I accidentally ran it as root and thus the 
>file was now read-only).
> 
> 2) During balancing, the ability to change the starting balance. I imported accounts 
>from another app, which of course had a balance.. but when I went to reconcile them 
>later GnuCash insisted that the opening balance be "$0.00".
> 
> 3) The ability to switch the order of the fields on the register page. Not a big 
>deal, but in other applications, and in fact in my actual checkbook, the deposit and 
>withdrawl fields are opposite of what they are in GnuCash.
> 
> 4) An option to have it prompt you to automatically save a copy of your file to fd0. 
>Admittedly though, I'm not sure how well this would work when you have to be root to 
>mount the floppy.
> 
> Thanks for listening, and again thank you for GnuCash :)
> 
> -Steve


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Precision

[linas]

Forwarding to the mailing list ...

It's been rumoured that Joshua said:
> 
> hello,
> 
> I am not a developer so I could not go in and fix this, but maybe some
> one on the development team could.
> I do a lot of trading in penny stock, but GNUcash  rounds to two point
> precision when I enter .017.  This is a
> very large problem when you are buying 100,000 shares of a stock at .017
> not .02.

It's doing the rounding only for display, but the actual math should 
still be correct.  If not, there's a bug ...

> Thank you for any help -- I looked through the doc and could not find a
> way to set precision , 

Its now on the list of things to do ...

> but if there is a way
> please send it to me.
> 
> Joshua SS Miller
> 


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]