Re: [PATCH] fr.po update

[Christian Stimming]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Applied to SVN (branch-2.0). Thanks a lot.

Christian

Fabrice Kurz schrieb:
> please find enclosed the latest update post r15147.
> Everything should be translated (3662 strings).
> 
> regards, 
> 
> 
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRcL+pWXAi+BfhivFAQLm9wP/bkOXMvcO7GJo5peDjXKpoZzBHBGkXypc
M+ICDmKWPzxgKPjGBPzdmdvBhk4BtlFoKJdZiiTHI7X23i2D/pWIJse5pkDTftHL
WG9k0iy0rQO12TEjyPVv28oWGabkKMAHWtIvUjxUgcYt/IoJ6kzEVEzN0JU23BLE
Yf9fiyvEHsg=
=8BhO
-END PGP SIGNATURE-
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

file versioning [WAS: Re: r15486 - gnucash/trunk/src - SX "enabled" patch from Peter McAlpine <[EMAIL PROTECTED]>.]

[Josh Sled]

On Thu, 2007-02-01 at 11:58 -0500, Derek Atkins wrote:
> Ideally, EVERYTHING would be "like" a KVP-frame..  But using Gobject
> properties and GValue (or perhaps GNCValue, so we can define our own
> GValue types)...  Then we always load (and save) all properties, and
> hopefully don't have to know a-prori all the properties we might want
> (or need) to save.

We might be talking past each other, but I don't consider a named
property (gobject property or otherwise) any different from a named
struct/object field ... but I do consider it different from an arbitrary
dictionary of name/value pairs (e.g. a kvp-style structure).  I
certainly don't want every GNC object to be struct GncFooBar
{ g_hash_table *fields; }, but I don't think that's what you're
suggesting...


...we could consider having an "overflow" bucket on objects: all known
tags are copied into their fields, and unknown fragments are just copied
literally into this overflow area.  Then, on file-write, we could
re-emit the "unknown" sections literally in their containers.

The XML world has two terms that are useful in thinking about this:
must-understand and must-ignore.  In must-understand, processors must
refuse to load the file if there is an element they don't understand.
In must-ignore, processors must simply ignore them [*].

[*: In HTML/document oriented processing, there's two variants of
must-ignore [1]: must-ignore-all (the whole subtree is ignored) and
must-ignore-container (the intervening container is ignored, but any
recognized child elements (tags and text) are presented as if the
container wasn't there). We're talking about must-ignore-all, here.]

[1] http://dev2dev.bea.com/pub/a/2004/05/soa_orchard.html

In some technologies (e.g., SOAP), these concepts are explicitly in the
XML data, as attributes on tags; an element will indicate if it can must
be ignored or understood for the processor to process it.  I don't think
we want this level of granularity.  We have the overall file version
number as a global "must-understand" field. :)

I guess for processors that re-emit the content, there's two variants of
must-ignore processing: retain and discard.  We're talking about
"must-ignore+retain", here.


Of course, this is not without potential problems; here's an
semi-grounded example. Let's call the file-format and software versions
v1 and v2, for simplicity; these don't correspond to gnc data files v1
and v2, they're just sequential abstract versions.  In v2, the concept
of "Mumbles" are introduced.  These Mumbles hold references to Accounts.
As part of the v2 code, when an Account is removed, the user is queried
for the disposition toward the sub-Mumble which references the Account.
This is all pretty plausible; SX template transactions behave similarly.

If v1 opens the v2 data, under must-ignore+discard, the Mumbles are
discarded, and thus can never become inconsistent!  :)

If v1 opens the v2 data, under must-ignore+retain, the Mumbles are
retained, but ignored (and we informed the user as much :).  Invariably,
the user deletes an Account that a Mumble references.  :) As this is v1
code, it doesn't understand that the consistency of the Mumble must be
maintained.  v1 writes out the revised Accounts, and the unmodified
Mumbles.  When v2 opens the v1-saved datafile, it must run some sort of
consistency check to look for that potential condition, and query the
user for the repair activity.

I guess that this is really how gnc should behave anyways.  Anything
could happen to the data file, and the data file could contain anything.
But it bears noting that we don't really do much in the way of load-time
consistency checks now.


Must-ingore+discard is "pessimistic" versioning; its impossible to solve
all problems, so we refuse to allow any problems, at very high cost.
Must-ignore+retain is "optimistic" versioning; the Mumbles will
hopefully, probably not become inconsistent in most cases ... the user
can hopefully do the right thing ... the receiver (the v2 software)
makes it right, with respect to consistency of data only it can
understand.


For completeness, what are the use cases, here?

-- The "failed" upgrade: v1->v2->v1.

In this case, the user tries out the new version (2.0), tries new
features (budgets), but decides to revert to the old version (1.8).
Here, they probably do want to discard the novel data, so they have a
"pure 1.8" datafile again.

-- The "lateral", switching between processors.

In this case, the user or developer is switching between roughly the
same versions, but with different processing options enabled.  For
instance:

- gnucash-stable
- gnucash-stable, but built with OFX support
- gnucash-svn
- some "cashutil"/"gnc-cli" that only processes core/engine objects in
  a simplified manner on the command-line.

Especially in the modularized world we live in, modules (business, ofx,
even maybe user-specific reports) have module-specific content to save.
I also think we should do away with all data storage that'

Re: r15486 - gnucash/trunk/src - SX "enabled" patch from Peter McAlpine <[EMAIL PROTECTED]>.

[Josh Sled]

On Thu, 2007-02-01 at 22:24 -0500, Peter McAlpine wrote:
> In this case would it be possible to partially avoid the issue by not  
> outputting the enabled tag if the SX is enabled (because it defaults  
> to true)?

We shouldn't elide fields we are aware of.  Explicit is better than
implicit.


> Would this be a quicker solution than fully implementing KVPs:
> Whenever unrecognized tags are found just read the tag into some  
> buffer and when the the object is to be outputted then output the tag  
> just as it was read in.

I don't think it's quicker, actually, but it's probably the right thing.


> Increment the xml version whenever there's new tags added that are  
> completely incompatible. Refuse to load newer versions.

This we do do, I think.  There's not a version number on the root
element, though the tag itself serves that purpose.  In fact, individual
objects have their own version numbers, including the , which
is the practical root of the datafile.

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


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

printing reports

[Villeneuve, Marie-José]

Hello,

I've been trying to print a report which shows the total federal and provincial 
taxes per month and just can't do it.

I really would appreciate if you can refer me to a site or specific 
documentation to able me to print this kind of report.

Thanks
Marie-José Villeneuve
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: printing reports

[Derek Atkins]

Try a Transaction Report or Account Summary Report and choose your
two Tax accounts.

-derek

Quoting "Villeneuve, Marie-José" <[EMAIL PROTECTED]>:

> Hello,
>
> I've been trying to print a report which shows the total federal and 
> provincial taxes per month and just can't do it.
>
> I really would appreciate if you can refer me to a site or specific 
> documentation to able me to print this kind of report.
>
> Thanks
> Marie-José Villeneuve
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>



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


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

Re: Accounts Hierarchy sets for "fr_CA"

[Christian Stimming]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Spel schrieb:
> Christian ,
> 
> Attached are sets of accounts hierarchy in French for Canada.
> 
> If it suits you, it could be incorporated into SVN.

Great! Thank you very much. I've added these to SVN now (both trunk and
branch-2.0). They will be in 2.0.5.

Regards,

Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRcNJHWXAi+BfhivFAQJshQP/aNGO2HoEkSUgaDpHlI+KGVCOFSpw9VK0
ZyxEyvMIic7dD7AW0aNNZhN8VM+aVWOLi3kU0uHtp4TzXEsn6AK0Xbv9gPONhAMi
W2RT9pKrTyzmvgfzdksTKK4lJL5goSudXaH9ySvDdVjxutRKRTKSQtSkbX54gk3b
5SrZcCRxXs4=
=qc8V
-END PGP SIGNATURE-
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

A couple of questions

[John Schmerge]

Hi guys,

  I'm a developer who's been using gnucash for about six months and
really like the program... It's allowed me to really start to track some
things regarding my finances that I never thought about. Anyway, I'd
like to start helping out with the development. Being that its a fairly
large application and that my experience with scheme is fairly limited,
can anyone give me some ideas of a couple of smaller tasks that I could
start with that will get me some familiarity with the code-base as well
as get me up to speed with scheme?

Just so you guys have some idea of my background, you can take a look at
my resume at http://www.speakeasy.org/~schmerge/resume.html

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

Re: A couple of questions

[Derek Atkins]

Quoting John Schmerge <[EMAIL PROTECTED]>:

> Hi guys,
>
>  I'm a developer who's been using gnucash for about six months and
> really like the program... It's allowed me to really start to track some
> things regarding my finances that I never thought about. Anyway, I'd
> like to start helping out with the development. Being that its a fairly
> large application and that my experience with scheme is fairly limited,
> can anyone give me some ideas of a couple of smaller tasks that I could
> start with that will get me some familiarity with the code-base as well
> as get me up to speed with scheme?

Where does this idea keep propagating that you need to know scheme to
work on gnucash?  Yes, GnuCash uses scheme, and some parts are written
in scheme, but only about 15% of the source code is in Scheme.  About
80% is in C.I really wish we could finally kill this idea that you
have to know scheme to work on GnuCash.

Having said that, if you want to learn Scheme then I'd recommend that
you google for "MIT Scheme Documentation".  It's a great resource.

As for what to work on.. Well, what would you LIKE to work on?
Some of the projects that I think need to get done:

  * register rewrite.  There's a branch for this, but the project needs
get finished.  We'd also need to make sure the new register works for
Accounts, SXes, and the business Invoices.
  * qif rewrite.  I started to rewrite the QIF importer but never finished.
This way we can hook the qif import into the same UI as OFX and HBCI
importers, and also get rid of some of the scheme!  :)
  * GDA.  Maybe Phil wants some help?
  * QOF-GObject.  Maybe Daniel wants some help?

I'm not sure what other active development projects are out there at the
moment.

Another option is to go over Bugzilla, triage the bugs, try to reproduce
them, and maybe take a stab at fixing them.

> Just so you guys have some idea of my background, you can take a look at
> my resume at http://www.speakeasy.org/~schmerge/resume.html

-derek

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

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

Re: A couple of questions

[Josh Sled]

On Fri, 2007-02-02 at 14:31 -0500, John Schmerge wrote:
>   I'm a developer who's been using gnucash for about six months and
> really like the program... It's allowed me to really start to track some
> things regarding my finances that I never thought about. Anyway, I'd
> like to start helping out with the development. Being that its a fairly
> large application and that my experience with scheme is fairly limited,
> can anyone give me some ideas of a couple of smaller tasks that I could
> start with that will get me some familiarity with the code-base as well
> as get me up to speed with scheme?

Very little of gnucash is in scheme.  At this point, mostly only the
reports.  Besides, if you have programming experience, you can pick up
enough scheme to be able to grok gnucash's use of it pretty easily.

As for getting yourself into development:

- build it from sources 

- fix a bug that's vexing you, or an existing bug


  There are a couple of gnome-love 
bugs there that are explicitly for beginners to the source,
unfortunately they both look to be scheme/report bugs...

- expand from there.

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


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Accounts Hierarchy sets for "fr_CA"

[Spel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christian Stimming a écrit :
> Spel schrieb:
>> Christian ,
> 
>> Attached are sets of accounts hierarchy in French for Canada.
> 
>> If it suits you, it could be incorporated into SVN.
> 
> Great! Thank you very much. I've added these to SVN now (both trunk and
> branch-2.0). They will be in 2.0.5.
> 
> Regards,
> 
> Christian

Christian,

I just noticed that files I supplied are utf-8 encoded, while those of
other locales all seem to be ISO-8859-1.  I am new to translation, and
don't if problems could arise for other platforms. If needed I could
change my default encoding in Kate or KBabel.  Let me know.

Such a question might look trivial to you developers, but I did not know
if, on such matters, communication channel should be through the list,
or directly to Christian.

Regards,
Serge
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFw6FBBa7LHmzax9QRAkkWAJ9vlCL63I3Oyt7KfZ50aybH0x2S+wCdG6jO
DIVFqPMAKjgvHbwnxHs2z/g=
=KE1I
-END PGP SIGNATURE-
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Accounts Hierarchy sets for "fr_CA"

[Derek Atkins]

Quoting Spel <[EMAIL PROTECTED]>:

> Christian,
>
> I just noticed that files I supplied are utf-8 encoded, while those of
> other locales all seem to be ISO-8859-1.  I am new to translation, and
> don't if problems could arise for other platforms. If needed I could
> change my default encoding in Kate or KBabel.  Let me know.
>
> Such a question might look trivial to you developers, but I did not know
> if, on such matters, communication channel should be through the list,
> or directly to Christian.

UTF-8 is fine.  I think using UTF-8 is recommended nowadays.

-derek

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

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

SX event handler behaviour (was SX Projection Report/SX enable/disable)

[Peter McAlpine]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

We discussed some things via IRC but a couple questions remain...

On 31-Jan-07, at 10:39 PM, Josh Sled wrote:
> 
> '_gnc_sx_instance_event_handler' should be modified to ignore
> non-enabled SXes that it receives updates about; I've added a fixme in
> the code about it.

Am I correct in that this handler exists to update an open SLR when  
SX's are edited/added/removed? If this is the case then is merely  
ignoring non-enabled SXes what we want to do?

How about this behaviour:
MODIFY event:
If instances for the SX are not found in the model and the SX is  
enabled then generate the instances and add them to the model.
If instances for the SX are found in the model and the SX is now non- 
enabled then remove the instances from the model.
Otherwise the usual behaviour

REMOVED event:
No change here, if the instances aren't found in the model, then  
don't remove them, otherwise the SX was enabled and deal with the  
event as per usual.

You've got a fixme at this event but I'm not sure why. Perhaps you  
were assuming that if we ever removed an SX but no instance exists  
then it'd be an error? Now that it's possible for a SX to not put any  
instances into the model we can treat this as a potentially valid event?

ADDED event:
If the SX is non-enabled then it should not generate any new instances.

> 

Hmmm, I went to look at whether I'd be able to see the 'printf("err 
\n")' you put in the REMOVE event by trying to remove a SX with it's  
frequency set to "None" but I was unable to even do this. The SX  
editor popped up a dialog to confirm I wanted to set an SX that would  
never run (to which I replied "Yes") but the change to the SX was not  
saved. Strangely enough, when I went to edit it again I set the  
Recurrence Frequency to "Weekly" and was incorrectly prompted to  
confirm that I wanted to create a SX that would never run. I'm  
assuming this should not have happened this way...?

Another issue I've noticed is that the calendar should not show  
instances for non-enabled SX's or SX's that will never run (if I can  
ever create such a SX), do you agree?

Thanks for all your feedback!

- -Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFxAeFeeKWVnwTIPIRAsBcAKDIsOtduwhAj35si/E9uYX5e5NC/QCgu12E
xheeti3FTcTktTFFx6hp0OU=
=e74x
-END PGP SIGNATURE-
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel