Re: data file differences in 2.2
Kevin HaleBoyes [EMAIL PROTECTED] writes: I tested it out - using a 2.2 saved file in the 2.0 version. I noticed that the display shows the Root account and it now prefixes all account names. Visually not great but whatever. Right. I did notice one other thing. 2.0 doesn't know about the ROOT account type so it changes the type to NO_TYPE. I'm wondering how 2.2 will respond to that? Haven't tried it yet. What version of 2.0.x are you using? I /think/ that 2.2 is smart enough to convert that back to a ROOT account. Thanks, K. -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: data file differences in 2.2
Derek Atkins wrote: Kevin HaleBoyes [EMAIL PROTECTED] writes: I did notice one other thing. 2.0 doesn't know about the ROOT account type so it changes the type to NO_TYPE. I'm wondering how 2.2 will respond to that? Haven't tried it yet. What version of 2.0.x are you using? I /think/ that 2.2 is smart enough to convert that back to a ROOT account. 2.0.5 I've been poking around the code to see if it would convert it back to a ROOT account but I get lost once it starts dealing with the QOF code. I did notice what seems to be a bit of redundant code: Around line 450 in gnc-account-xml-v2.c it calls gnc_book_get_root_account() and if it returns NULL then gnc_account_create_root() is called. But, if gnc_book_get_root_account() finds no root account then it creates one and returns it. K. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: XPF Currency fix
Am Montag, 23. Juli 2007 21:25 schrieb Dominique Corbex: Hi: The XPF currency [CFP Franc Pacifique], used in French Polynesia, New Caledonia, Wallis and Futuna islands has 2 digits after the decimal point in Gnucash. That's wrong as the XPF currency makes no use of cents. (see http://www.wikipedia.com/wiki/Currency_codes and search for XPF) Please find in attachment an updated iso-4217-currencies.scm file. Thanks a lot. This has been added to SVN and will be fixed in the next release. (Just for future reference: Sending unified diff by diff -u or svn diff is actually preferred to sending the whole file, as it makes the evaluation of your change even easier.) But thanks for this in any case. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: dogtail test suite test harness
ahmad sayed [EMAIL PROTECTED] writes: Josh Said: you suggested some approach like Junit, I tried pyunit and it looks nice to me, do you have any issues regarding using it to organize our test cases. It looks like you've started down that path. Whatever you're comfortable using is good, but things that are established and will time (like python's `unittest` module) are always good to leverage. (good to leverag) sorry I didn't get the meaning of this expression, i hope it means that you agree with me on using pyunit :). Yes. :) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpmBY9gjMkbW.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: data file differences in 2.2
Hale Boyes, Kevin wrote: Derek Atkins wrote: Kevin HaleBoyes [EMAIL PROTECTED] writes: I did notice one other thing. 2.0 doesn't know about the ROOT account type so it changes the type to NO_TYPE. I'm wondering how 2.2 will respond to that? Haven't tried it yet. What version of 2.0.x are you using? I /think/ that 2.2 is smart enough to convert that back to a ROOT account. 2.0.5 I've been poking around the code to see if it would convert it back to a ROOT account but I get lost once it starts dealing with the QOF code. Just to recap... I have a data file saved by GnuCash 2.0.5. I opened that file in 2.2.0 and saved. I then took that file and opened and saved it in 2.0.5 which causes the Root account type to be set to NO_TYPE. If this file is then opened in 2.2.0 again it will not recognize the Root account properly. So, the Root account shows up in the display. I didn't check but I suspect it also got re-parented to another Root account. So, I'd say that once you've saved your data file in 2.2.0 you should not go back to 2.0.5 and save there. This has nothing to do with the data file change noted in the release notes (around scheduled transactions). Kevin. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SQL Backend?
Albert Lash [EMAIL PROTECTED] writes: Am I correct in my assumption that this code isn't actually used with the current, non-SQL, backend? That's right; each backend is basically stand-alone. Of course it shares a rough outline with the runtime object model and XML data-model, just by nature. Thoughts? I'm doing a bunch of work on pbooks right now and if any of it can benefit gnucash, I'll try to make it to happen. If you see concrete opportunities for sharing, by all means write it up. I'm sure it's going to come down to the models being just different enough, either because of historical warts or just reasonably different application functionality, that they data models will want to be different. Not to discourage, but it feels like an extra level of effort to try to keep two application's data models in some sort of sync. At the same time, I'd be really interested to know how different from the XRBL model gnucash is. I could just look at the specs, I guess. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpSr8JdDrfQ0.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: data file differences in 2.2
Hale Boyes, Kevin [EMAIL PROTECTED] writes: So, I'd say that once you've saved your data file in 2.2.0 you should not go back to 2.0.5 and save there. This has nothing to do with the data file change noted in the release notes (around scheduled transactions). Yea ... we should obviously make it stronger and more comprehensive for 2.2.1. Thanks for the legwork testing the back and forth between the versions! :) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpqOmZz4ZSSq.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: updated gnucash's french translation : fr.po
Christian Stimming [EMAIL PROTECTED] writes: One question: #. %s is the name of the weekday #: ../src/engine/FreqSpec.c:829 #, c-format msgid Bi-Weekly, %ss If second 's' is here to use the plural form, could you add a comment for translators? Oops. @jsled: If this should indeed be the plural form of the weekday, then this string is fundamentally broken from an i18n POV - you can't do it this simple in languages other than english. Many weekdays have plural forms that are built differently from each other in other languages. This string should be changed into Bi-Weekly, each %s Does not the translator effect the whole string? I was thinking that the translator would (not) use the trailing-s version depending on if it was appropriate for the translation. I could certainly add more detail in comments; I've started to do that with strings I've added recently. FWIW, the FreqSpec code is dead, and will be removed at some point. At the same time, there's basically-equivalent code in Recurrence, now. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpnpFwdAGS9C.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
FAQ update: request for help
The FAQ http://wiki.gnucash.org/wiki/FAQ has a bit of cruft, and hasn't
really gained a bunch of new items that we've seen with the 2.2 and even the
2.0 releases.
I sketched out a set of new FAQ entries. I'm looking for review of things I
might have missed, as well, as help in generating the copy/text of the
Answer. In some cases I've noted the dates of recent -user threads (see the
archives at http://lists.gnucash.org/pipermail/gnucash-user/) that might be
a good starting point for summarization.
If you have a few minutes to help, please pick one and respond. Even better,
please update the FAQ and just say that you've done so. :)
- to add
- Reply-To munging
- Database backend/branch status.
- Include history re: 1.8, PG backend, c.
- I've lost my account tree page?!
- File New New Account Page
- password protection of datafile?
- mostly in
http://wiki.gnucash.org/wiki/FAQ#Q:_Is_it_possible_to_provide_security_for_GC_data_using_CFS.2C_etc..3F,
but no one is going to phrase their question that way...
- The Register and CJK
- summarize 18-Jul thread, and others.
- ${something_bad} happened. :( How can I debug?
- run in terminal
- console output
- gnucash.trace (location difference between 'nix/osx and windows)
- reordering accounts?
- parent/child vs. sibling order
- delays in transfer between accounts
- summarize 06-Jul thread
- HOWTO: Class accounting
- summarize 02-Jul thread
- HOWTO: VAT
- this seems to be a permathread, and is already somewhat covered in the
FAQ.
- fix the ISO stock FAQ re:
- say private [stock] and options somewhere
- note specifically that you can type over the combobox to create new
types like private.
- Multiple bills with one Payment?
- Just use process payment. Applied in FIFO order. c.
- file extensions
- .xac (though same as the backups), .gnucash, .gnc.
- shared-mime-info registration
- to remove
- gnome2-related entries
- (most) gnucash-1.8-related entries
- to move
- a bunch of §4 (Using GnuCash) questions should be in §7 (Accounting).
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpiVGl3XTHz0.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Hi Guys
Just wondering if it would be possible for you guys to provide .autopackage files for gnucash for linux. I do plan on downloading and compiling anyway, but I'd love it if I could just double-click ;) Thanks for reading, hope I haven't wasted too much time! Daniel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: autopackage [was: Hi Guys]
Daniel James [EMAIL PROTECTED] writes: Just wondering if it would be possible for you guys to provide .autopackage files for gnucash for linux. I do plan on downloading and compiling anyway, but I'd love it if I could just double-click ;) (You might want to be careful with your subject line ... this one looks basically identical to other spam in the moderation queue.) We welcome the contribution of a (maintained) autopackage control file; we've had a few requests identical to this one, but no contribution. I note that we do have binary relocation support, from the 'BinReloc' package; c.f. http://svn.gnucash.org/trac/changeset/14862. I believe some of the motivation for this was autopackage. (I'm personally sympathetic to the idea that autopackage is ... broken. Still, I'd happily commit such a contribution.) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpsgqHMX7kGj.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Some Japanese translation: ja.po
Hiroto Kagotani [EMAIL PROTECTED] writes: Hello, I'm interested in using GnuCash in Japanese. I've just subscribed to this list and known someone is also interested in Japanese translation. Here I attach my first attempt of translation, though it is not completed yet at all. Great, it is much more than my attempt so far! -- BOFH excuse #381: Robotic tape changer mistook operator's tie for a backup tape. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SQL Backend?
That's right; each backend is basically stand-alone. Of course it shares a rough outline with the runtime object model and XML data-model, just by nature. Hmm, I'm a little confused now. The code referenced earlier had to do with GDM, right? And GDM was replaced by QOF? Or is it that they two are different, QOF is used for managing an XML flat file database, and GDM is used for SQL connectivity? I was thinking that QOF could be connected to a SQL backend via ODBC or something. If you see concrete opportunities for sharing, by all means write it up. Definitely. I still have a lot of learning about how GnuCash works though, as well as work to do on PBooks. I'm sure it's going to come down to the models being just different enough, either because of historical warts or just reasonably different application functionality, that they data models will want to be different. Not to discourage, but it feels like an extra level of effort to try to keep two application's data models in some sort of sync. It very well could be more work than its worth, but its at least worth finding out! :-) It is doubtful that the fringe data required by a bookkeeping system (like customers, vendors, and inventory) could be kept in sync, but it might be possible and worthwhile for the core (financial data only - accounts and transactions) to be interoperable. At the same time, I'd be really interested to know how different from the XRBL model gnucash is. I could just look at the specs, I guess. Here's some links I found helpful in researching XBRL: http://gl.iphix.net/ http://xbrl.emporia.edu/2006/index.php Is there a basic description of the GnuCash data model around anywhere? Is this information only accessible in the code at the moment? I've read about the accounts, transactions, and splits, and these coincide fairly well with pbooks' accounts, entries, entry_amounts, and transactions. - Albert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
