Re: Mailing List Options [was Re: Switching...]
On Sun, 2005-10-30 at 18:30 -0600, Stewart V. Wright wrote: * Josh Sled [EMAIL PROTECTED] [051030 18:21]: I can imagine a large class of -devel subscribers that would be put off by being forced into receiving every commit and its diff. Certainly I strongly concur with this. I guess that there are a number of us lurking on the -devel list either just out of interest or waiting to see if we can assist at some level that matches our coding/time constraints. I also strongly endorse this. I don't have the motivation to keep that current with development, or I'd already be subscribed to -commits (or whatever its called). Conrad. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CVS, Oct 30, Build errors on x86_64
On Sun, 2005-10-30 at 23:36 -0800, Karl Hegbloom wrote: I won't have time to try and fix these; I'm way behind on my Mathematics homework and should really be working on that instead... Hope this helps. Do yous have an AMD64 to test compile on? Only vicariously through souls like yourself... :) ...but the issue here isn't x86_64 specific: the GSF_CLASS_FULL macro errors in the lib/goffice/ code are due to a macro signature difference in =libgsf-1.12.1 and =libgsf-1.12.2. Neil Williams had put in a check re: libgoffice / libgsf to work around this on his Debian Unstable box. What system-installed versions of libgsf and libgoffice do you have? ...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: GnuCash design / new features
Quoting Brian Rose [EMAIL PROTECTED]: Well, for one it would be really awesome if the invoice template was similar to iBiz, http://www.iggsoftware.com/ibiz/index.html . 1. We don't want to have specific external targets from within gnucash like that - the reference you quote is a moving target and if we try to fix against it, it will always be a case of catch-up. I wasn't suggesting mimicking iBiz. Another option we've discussed previously is e-guile.. This would make invoice templates effectively hand-written HTML with embedded guile.. So if you wanted to change the look at feel of your invoice you would just edit the HTML until it looked how you wanted it to look.. And then the embedded guile interpreter would run the template you created and display it with the relevant information. Then we could also distribute a bunch of templates (similar to iBiz) and you could choose one or create your own. Unfortunately as I was looking for an e-guile link I noticed that the author restructured his website and the old page is no longer there. I just emailed him about it. As I recall e-guile was effectively a single source file, so we could just copy-and-paste it into GnuCash and then someone would just need to figure out how to integrate it into the report subsystem and set up a runtime environment for a report template. 2. Tips and advice on how to manage the gnucash codebase. The tools to use and links to their documentation. Conventions and when to use branches. 3. A concerted effort to bring the existing disparate docs into one cohesive whole that is relevant, friendly, welcoming, genuinely helpful and bridges the gap between the gnucash-docs package and the gnucash-devel archives. 4. Regular and consistent updates to all documentation components. Realistically, this can only be achieved by using a tool that provides write access to all developers with CVS/SVN commit rights plus a few others with documentation skills - i.e. some form of CMS. I'd recommend Drupal. Sounds good, but what do you think, Derek, about 2,3, and 4--directly above? I think they sound like a great idea. I would love for someone to dedicate time to coalescing all the various docs, finding out what docs are missing, what docs are duplicated, and honing down our docs into: user-docs (gnucash-docs package) dev-docs (in doxygen) build docs (README, HACKING, ...) arch docs (everything else, which bridges the gaps) I don't believe we'd need something like Drupal for this; I think this could all be done in CVS/SVN. Sincerely, Brian -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: src/engine/{qof,gnc}la-dir.h not being built
Josh Sled wrote:
Noticed during normal upgrade/build cycle (from a cvs update yesterday
evening, which was g2-latest), but I `make distclean`ed, re-autogen and
re-`make install`ed just to be sure...
... src/engine/{qof,gnc}la-dir.h is not being built:
qof.h:99:23: qofla-dir.h: No such file or directory
make[3]: *** [gnc-date.lo] Error 1
qofla-dir.h is not included in the BUILT_SOURCES variable which causes
this problem, I suppose.
The Makefile is set up in a way that qofla-dir.h and the whole qof files
will only be built if USE_LIBQOF is true. The variable qof_builds is
supposed to add qofla-dir.h to BUILT_SOURCES... hm... maybe writing
$(qof_builds) instead of ${qof_builds} helps? Or writing
BUILT_SOURCES += qofla-dir.h
in the USE_LIBQOF section helps?
Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing - Scheduled Transactions[/Register]
On Sunday 30 October 2005 9:09 pm, someone claiming to be Josh Sled wrote: snip On Thu, 2005-10-27 at 12:04 -0400, Tim Wunder wrote: In a related issue: It would seem to be a good idea to have the preferences dialog mirror the SX creation Options section. See screenshot screenshot no longer available Fixed; the prefs are closer to the dialog, now, both above and below the surface. ...jsled And it's beautiful :) pgpYHqhT7Ew4Q.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Since Last Run dialog
In gnc-1.8.11, when there were no transactions to create and only transactions to be reminded about, the Since Last Run dialog would offer the user a Finish button while displaying the current set of reminders. Also, the Back button would be disabled (grayed out), since the reminder list is the first window of the dialog. G2 just gives the user Cancel, Back, and Forward buttons, all seemingly active (although Back doesn't do anything). When you click the Forward button, a window displays Press apply to create these transactions even though there are no transactions listed, and there are none to be created. Tim -- Fedora Core release 4 (Stentz), Linux 2.6.13-1.1532_FC4 KDE: 3.4.3-1.0.fc4.kde, xorg-x11-6.8.2-37.FC4.49.2 09:30:04 up 5 days, 12:01, 5 users, load average: 0.14, 0.33, 0.71 MP3/OGG archive Total playlength : 7 days, 10 hours, 31 mins 30 seconds It's what you learn after you know it all that counts John Wooden pgpqwFdAQFaf8.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: build errors in src/backend/qsf/
Josh Sled schrieb: e.g make[4]: Entering directory `/home/jsled/stuff/proj/gnucash/src-g2/gnucash/src/backend/qsf' source='qsf-backend.c' object='qsf-backend.lo' libtool=yes \ depfile='.deps/qsf-backend.Plo' tmpdepfile='.deps/qsf-backend.TPlo' \ depmode=gcc3 /bin/sh ../../../depcomp \ /bin/sh ../../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../..-I.. -I../.. -I../../../src/backend -I../../../src/engine -DLOCALE_DIR=\/opt/gnc-g2-unstable/share/locale\ -I../../../src/gnc-module -I/usr/include/libxml2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O3 -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Werror -c -o qsf-backend.lo `test -f 'qsf-backend.c' || echo './'`qsf-backend.c gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -I../.. -I../../../src/backend -I../../../src/engine -DLOCALE_DIR=\/opt/gnc-g2-unstable/share/locale\ -I../../../src/gnc-module -I/usr/include/libxml2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O3 -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Werror -c qsf-backend.c -MT qsf-backend.lo -MD -MP -MF .deps/qsf-backend.TPlo -fPIC -DPIC -o .libs/qsf-backend.o qsf-backend.c:29:21: qsf-dir.h: No such file or directory Huh? In that directory, qsf-dir.h is added to the BUILT_SOURCES variable in the Makefile. That's about as correct as it can get, in order to ensure that this header is built before the rest of the stuff in this directory. Does your version of automake/autoconf somehow ignore BUILT_SOURCES? Maybe the docs of your automake might explain how to use the BUILT_SOURCES variable? I got autoconf-2.59 and automake-1.9.5 and with these the header is corretly built before everything else. (So that's probably true in src/engine as well). Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
Another option we've discussed previously is e-guile.. This would make invoice templates effectively hand-written HTML with embedded guile.. So if you wanted to change the look at feel of your invoice you would just edit the HTML until it looked how you wanted it to look.. And then the embedded guile interpreter would run the template you created and display it with the relevant information. Then we could also distribute a bunch of templates (similar to iBiz) and you could choose one or create your own. I like this idea. Unfortunately as I was looking for an e-guile link I noticed that the author restructured his website and the old page is no longer there. I just emailed him about it. As I recall e-guile was effectively a single source file, so we could just copy-and-paste it into GnuCash and then someone would just need to figure out how to integrate it into the report subsystem and set up a runtime environment for a report template. Once we have access to that source I would like to look into it. Sounds good, but what do you think, Derek, about 2,3, and 4--directly above? I think they sound like a great idea. I would love for someone to dedicate time to coalescing all the various docs, finding out what docs are missing, what docs are duplicated, and honing down our docs into: user-docs (gnucash-docs package) dev-docs (in doxygen) build docs (README, HACKING, ...) arch docs (everything else, which bridges the gaps) I don't believe we'd need something like Drupal for this; I think this could all be done in CVS/SVN. Hmmm, but is there anywhere that says in stuff like in version 2.5 we will have whatever, and in v. 3.0 will be these features as well. A current roadmap I guess. Is it not neccessary to have all this and the docs above on the/a website? Right now there is the wiki, gnucash.org, and then independent developers' sites all with different info. I want to sound rude, just that I was confused at where Gnucash is going after G2, so I thought if I am confused maybe others are as well--hence the website suggestions. For example, I read the QSF part on Neil's site and now I wonder what QOF/QSF has to do with G2, SQL backend, multi-user support, I am sorry and maybe I am a bit green on developing such an app, but I just don't get any of the stuff with QOF/QSF. Is it part of the Free the data concept or to support multiple backends/platforms or what? Sincerely, Brian -- Contagious Design! web . design . photo Brian Rose . web programmer (604)-630-2426 . brianATcontagiousdesignDOTnet ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Adding a Payroll calculator
On Sun, 2005-10-30 at 20:03 -0500, [EMAIL PROTECTED] wrote: Conrad Canterford wrote: snipping Jay, On my very quick look at what you had there, it makes various assumptions about the structure and nature of the payroll deductions. Not adaptable to different structures as they exist in different countries. For example, most of our tax deductions work a graduated scheme, which does not lend itself to a flat-rate percentage calculation (and for added complication, often includes a tax-free amount). Other deductions work as a fixed percentage of the total (like you appear to be showing). Still other deductions are based on units of work (hours usually). For example, in WA state you collect from employees at a rate per hour for LI and also accrue liability for employer at another rate per hour. Some of those employees are salaried and have no set hours and in that case you have to know to collect on 160 hours per month regardless of what hours they work. Also, many taxes hage wage bases above which the tax does not apply... . Your also seem to require the accounts person to know/calculate the appropriate percentage each time (or rely on the fact that it hasn't changed from last time) - that is all good for permanent employees with very little variation, but does nothing for people employing casual staff for example, where their earnings may vary from week to week. For reporting purposes, you will almost certainly need to record how much of each deduction you take from each employee. This could probably be done in accounts within the gnucash account tree, and might not be that hard, but you'd need to think about how that was structured. I admit to having no concept whatsoever how these things are handled in countries other than my own (I've never employed staff anywhere but here). Some agencies want reporting based on when work was performed and some want it based on when wages were paid. I guess what I'm saying is that such simple approach does not really solve the problem. Having said that, it might nevertheless provide a basis for someone else to work on to provide a more generic approach. I'm actually envisaging something along the lines of a plug-in module (specific to each country) which calculates those percentages for you for all the taxes and deductions. Having not seen any code, I cannot say how practical that might be. I have to agree that the problem is definitely NOT simple. However, soemthing is better than naught. A Conrad. For discussion, this was why I had at first suggested a payroll calculator under GnuCash-tools. Using a framework much like the Financial calculator by letting the user edit any taxable percentages. Or, as I found your gnc_Employee and gnc_business classes. You could add a table (class) specifically for payroll taxes that would reflect upon the nature of the employee and the business. You started by adding a rate classification. Seems only logical to add to the employee class: Type key (hourly, salary, commission), Job description key (laborer, assembly, management). And for the Business class: An industry key, to match the country's industry classifications. Example For US: matching the IRS business classification (for LandI rates). The entries for these would be presented while one is creating the company and or employee (GnuCash-Business-Employees-New). Then these keys would be assigned to an editable field by the account creator allowing for any changes/updates to the tax tables issued by the respective governments. These factors would be used when entering any wage or salary payments to the employee to automatically calculate deductions. Just a suggestion. Jay Scherrer ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
On Mon, 2005-10-31 at 06:59 -0800, Brian Rose wrote: Hmmm, but is there anywhere that says in stuff like in version 2.5 we will have whatever, and in v. 3.0 will be these features as well. A current roadmap I guess. Is it not neccessary to have all this and the docs above on the/a website? Right now there is the wiki, gnucash.org, and then independent developers' sites all with different info. I want to sound rude, just that I was confused at where Gnucash is going after G2, so I thought if I am confused maybe others are as well--hence the website suggestions. This is a good point (except for the wanting to sound rude part ;). We've been really focused on the G2 port and 2.0, and intentionally haven't talked with too much rigor about post-2.0, at the same time there's been a lot of discussion over the last year or so, and I think it breaks out like: - General simplification - Report handwavecleanup/handwave - Scheme removal - Finalize QOF extraction - Fix modularity system - Features - DB-backend/SQLite integration. - Budgeting - Book closing - Lots - SX using QOF (to support above) - Register rewrite in simple widgets. It might be possible to plan these out into specific releases/timeframes if we had regular releases and more than really-part-time developers. Right now, it's hard to have a realistic roadmap that's more formal. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: build errors in src/backend/qsf/
On Sun, 2005-10-30 at 18:03 -0500, Josh Sled wrote: There are similar errors in qsf-xml-map.c and qsf-xml.c. Similar to the src/engine/gncla-dir.h issue, if I manually build qsf-dir.h, the errors go away. Derek reports this (and the src/engine/ issue) does not occur for him with a clean tree, so perhaps it's just me, somehow. I'll dig into it some 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
Proposal: CVS - SVN switchover: Nov 6th, hopefully
After coordinating with David Hampton last night, he's hopeful to have the G2 - HEAD merge done by this coming weekend of Nov 5/6th. As such, I intend to do the CVS - SVN repository migration this coming weekend as well. Proposal: On Sunday November 6th we will switch from CVS to SVN. IF YOU HAVE ANY UN-COMMITTED STATE, YOU MAY WANT TO CHECK IT IN ASAP. Certainly if you're unable or unwilling to commit your changes, you can generate a unified diff with CVS, checkout the tree with SVN, and apply the diff to the new tree... but you should be aware that you'll need to do this. As there is an element of uncertainty in the G2 - HEAD branch collapse, this MIGHT NOT OCCUR. But, hopefully, it will all come together. If it does not occur this weekend, we'll try for next weekend, Nov 12/13th. As well, there's still a couple of configuration items to resolve: - Branch/tag Naming: it seems like a rename [gnucash-1-6-branch - gnucash/branches/1.6] is reasonable. Last-minute objections? - Mailing Lists: I'd before said that the non-diff mailing list might go away, but now I'm leaning toward mirroring the current mailing-list configuration exactly. Note that this has nothing to do with the other mailing-list discussion, we can change things later... for the moment, I just want parity with what we have now for simplicity. ...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: Proposal: CVS - SVN switchover: Nov 6th, hopefully
Josh Sled schrieb: After coordinating with David Hampton last night, he's hopeful to have the G2 - HEAD merge done by this coming weekend of Nov 5/6th. As such, I intend to do the CVS - SVN repository migration this coming weekend as well. Proposal: On Sunday November 6th we will switch from CVS to SVN. Yeah! Great! Way to go! I totally agree. As well, there's still a couple of configuration items to resolve: - Branch/tag Naming: it seems like a rename [gnucash-1-6-branch - gnucash/branches/1.6] is reasonable. Last-minute objections? No objection from here. Sounds good. - Mailing Lists: I'd before said that the non-diff mailing list might go away, but now I'm leaning toward mirroring the current mailing-list configuration exactly. Note that this has nothing to do with the other mailing-list discussion, we can change things later... for the moment, I just want parity with what we have now for simplicity. I agree that keeping the current configuration is probably the easiest choice for now. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CVS, Oct 30, Build errors on x86_64
On Mon, 2005-10-31 at 09:00 -0500, Josh Sled wrote: On Sun, 2005-10-30 at 23:36 -0800, Karl Hegbloom wrote: I won't have time to try and fix these; I'm way behind on my Mathematics homework and should really be working on that instead... Hope this helps. Do yous have an AMD64 to test compile on? Only vicariously through souls like yourself... :) ...but the issue here isn't x86_64 specific: the GSF_CLASS_FULL macro errors in the lib/goffice/ code are due to a macro signature difference in =libgsf-1.12.1 and =libgsf-1.12.2. Neil Williams had put in a check re: libgoffice / libgsf to work around this on his Debian Unstable box. What system-installed versions of libgsf and libgoffice do you have? libgsf-1-dev 1.12.3-3ubuntu3 libgsf-gnome-1-dev 1.12.3-3ubuntu3 libgoffice-1-dev was not installed at all. I just installed version 0.0.4-1, also from Ubuntu. I don't know how it was able to finish 'configure' and compile as much as it did if it requires libgoffice. Perhaps a 'configure.in' check for that is not present? It probably would fail to link without it. -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
Oh, no! different info. I want to sound rude, just that I DO NOT want to sound rude! Yikes! Sorry! This is a good point (except for the wanting to sound rude part ;). yeah. Well, people really do judge a book by its cover and a project by its interface and its website-E.g., Does it have lots of cool original eye candy that looks fairly new, So, if we want to attract more users, developers, etc--this is why I like Firefox. Looks great, but is a good product too. it breaks out like: - General simplification - Report handwavecleanup/handwave - Scheme removal - Finalize QOF extraction - Fix modularity system - Features - DB-backend/SQLite integration. - Budgeting - Book closing - Lots - SX using QOF (to support above) - Register rewrite in simple widgets. Ok. Sincerely, Brian -- Contagious Design! web . design . photo Brian Rose . web programmer (604)-630-2426 . brianATcontagiousdesignDOTnet ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Adding a Payroll calculator
Jay Scherrer wrote: snip For discussion, this was why I had at first suggested a payroll calculator under GnuCash-tools. Using a framework much like the Financial calculator by letting the user edit any taxable percentages. Or, as I found your gnc_Employee and gnc_business classes. You could add a table (class) specifically for payroll taxes that would reflect upon the nature of the employee and the business. You started by adding a rate classification. Seems only logical to add to the employee class: Type key (hourly, salary, commission), Job description key (laborer, assembly, management). And for the Business class: An industry key, to match the country's industry classifications. Example For US: matching the IRS business classification (for LandI rates). The entries for these would be presented while one is creating the company and or employee (GnuCash-Business-Employees-New). Then these keys would be assigned to an editable field by the account creator allowing for any changes/updates to the tax tables issued by the respective governments. These factors would be used when entering any wage or salary payments to the employee to automatically calculate deductions. Just a suggestion. Jay Scherrer IMHO, based on the broad requirements of many jurisdictions in the gnucash user base, the more generic the solution the better. I suppose that at some point it becomes no easier than using a spreadsheet, but bypasses the importing requirements of that solution. In my past thoughts on this, it seemed reasonable to come up with a handful of different classes of payroll items with all the numbers (tax percentages, wage bases, etc) applied directly by the user. Ummm.. sort of like setting up tax tables. Create a table, assign a name and a variety of features for that particular instance and save it. Then apply the appropriate items to each employee as they are created/edited. Is this what you are getting at? Each employee record would point to its payroll record and have any number of fields for various requirements (wage, taxes, deductions, etc). Some of the fields could have a prompt flag that would prompt the user for this information at the time payroll is executed. Obvious one would be hours worked, but other could be reported tips or reimbursements. IIRC I had narrowed this down to just a handle of classes to get most thigns to work. (My knowledge of gnucash code is - 0 and my coding is rusty - infinity so my vocabulary above is probably wrong ;) ). When you process the payroll, at the point that you execute the payroll, the pertinent information is calculated and then stored in the payroll transaction (probably in the memo and description fields). Am I following you correctly? are we talking about the same thing? A ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Mailing List Options [was Re: Switching...]
Josh Sled wrote: I can imagine a large class of -devel subscribers that would be put off by being forced into receiving every commit and its diff. Certainly filtering and mailers are our friends, but it really does seem like different lists to me. Personally, I disagree. Currently, I generally ignore whatever large blocks of code show up on this list and its easy to do. My hope is that someday I'll get my act together and learn enough of the code to read and understand these things. IOW, it wouldn't put me off. A ...jsled ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CVS, Oct 30, Build errors on x86_64
On Monday 31 October 2005 5:45 pm, Karl Hegbloom wrote: ...but the issue here isn't x86_64 specific: the GSF_CLASS_FULL macro errors in the lib/goffice/ code are due to a macro signature difference in =libgsf-1.12.1 and =libgsf-1.12.2. Neil Williams had put in a check re: libgoffice / libgsf to work around this on his Debian Unstable box. What system-installed versions of libgsf and libgoffice do you have? libgsf-1-dev 1.12.3-3ubuntu3 libgsf-gnome-1-dev 1.12.3-3ubuntu3 libgoffice-1-dev was not installed at all. I just installed version 0.0.4-1, also from Ubuntu. With goffice 0.0.4 installed, G2 will omit the internal goffice code and bypass the macro problem. I don't know how it was able to finish 'configure' and compile as much as it did if it requires libgoffice. Perhaps a 'configure.in' check for that is not present? It probably would fail to link without it. I still need to update configure.in to prompt for goffice if libgsf-1 = 1.12.2 but it's best to get the G2 branch merged into HEAD and the change to SVN before I go tweaking configure.in again. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpkyMpsVKlwO.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: autogen.sh stops when trying cvs g2 build...
On Sunday 30 October 2005 2:12 pm, Arnout Engelen wrote: checking for QOF, version = 0.6.0... Package qof-1 was not found in the pkg-config search path. Perhaps you should add the directory containing `qof-1.pc' to the PKG_CONFIG_PATH environment variable This doesn't sound right to me either No, that is absolutely correct. You've snipped the relevant part that comes just after this - QOF not found, using internal QOF library. The same thing happens with goffice. I'll see if I can stop some of the errors being displayed - should be possible with --silence-errors -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp499JqY5tHH.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing
David Hampton wrote: On Fri, 2005-10-28 at 09:41 -0700, Andrew Sackville-West wrote: Volker has been so inspiring that I've gotten motivated to do some testing. :-) 1) Mouse wheel is inconsistent: When all the accounts are expanded in the accounts tab so that they fill the window, the mousewheel behaves as expected by scrolling. This does not funtion in the register. I committed a fix for this on the 23rd. How recent is your tree? Have now pulled a new cvs (10/30) and compiled, so mouse wheel is fixed. :D 4) selecting an account from within a report using the hotlinks increases size of the window by a few pixels each time. I don't see this problem on my FC4 system. What distribution are you using? Also, which report was this so I can make sure I'm accurately recreating the scenario where the problem occurs. This problem continues. Also, still no charts. I have tried many different charts with different dates, account selections etc still says: unable to push bar chart -- or -- unable to display pie chart A David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design - the role of QOF and QSF
On Monday 31 October 2005 2:59 pm, Brian Rose wrote: Right now there is the wiki, gnucash.org, and then independent developers' sites all with different info. I want to sound rude, just that I was confused at where Gnucash is going after G2, so I thought if I am confused maybe others are as well--hence the website suggestions. For example, I read the QSF part on Neil's site and now I wonder what QOF/QSF has to do with G2, SQL backend, multi-user support, QOF is a separate library now with it's own development path that will retain gnucash as a client - incorporating feature requests from gnucash alongside requests from other client programs and architectures. Other applications using QOF include GnoTime, Pilot-QOF and cashutil. QOF and QSF have important benefits for GnuCash and, yes, it is all linked to data freedom. QOF is to include full SQL backend support via libgda and the gnome-db plugins. This will mean that gnucash will inherit generic backend support via QOF for nearly all the databases you can name - SQLite, MySQL, Postgres, Oracle, Sybase, ODBC, FireBird/Interbase, IBM DB2, mSQL and MS SQL server, as well as MS Access and xBase files. Data in any of these sources can be shared with any other backend and with any QOF client. (QOF is likely to move to beta once this is done). QOF is also going to be built for embedded systems and already has a client application to work with Palm OS devices. On larger embedded systems, QOF can run on the mobile device and provide query support on the move - many PDA utilities lack the ability to use data from other programs on the same device and native QOF can solve this problem. The idea is that the user data should be as free as the source code that creates it. Beating vendor/application lock-in not by reverse engineering but by making lock-in itself increasingly redundant. Revealing the true colours of lock-in - the selfish obsession of proprietary developers. This means that GnuCash G2 gains access to data from a rapidly increasing range of sources making it far easier to work with your GnuCash data in other applications and to create GnuCash data from other tools - like a PDA - without losing the ability to bring the data back into gnucash later on. Lots of people enter business data like expenses onto a mobile device of some kind. QOF - as a fundamental component of gnucash - can provide low-level generic access to all these pieces of data making data entry automation more available. QOF will be able to go onto platforms that could never support gnucash and yet provide gnucash with access to the available data on that platform. Indeed, each and every QOF client will inherit the same levels of access to each other QOF client and each QOF backend, on whichever platform QOF is available. Pilot-QOF wraps QOF around code from pilot-link to provide a QOF interface for all devices supported by pilot-link using QSF XML. The same can be done for other applications - wrapping QOF around existing code to create a new QOF client that can share data with any other QOF client using any available QOF backend. I am sorry and maybe I am a bit green on developing such an app, but I just don't get any of the stuff with QOF/QSF. Is it part of the Free the data concept or to support multiple backends/platforms or what? Both and all. 1. QOF provides simple methods to only export the gnucash data relevant to a specific query. 2. QOF retains the integrity of that data so that it can be reimported into gnucash and updated from gnucash. 3. QOF stores this data in whichever backend is chosen - QSF is the default backend and will be the only backend guaranteed to be available for ALL QOF clients. 4. QSF is a generic and validated XML that can support detailed and recursive SQL-type queries for data mining and data extraction / reporting. Any gnucash data can be made available to a Perl/PHP/Python/whatever script and passed to any number of customised scripts to provide an infinite number of reports and analyses. 5. QOF provides the data interchange that allows disparate data sources to exchange data without loss of data integrity. This is mostly in the future - but I believe it all to be attainable. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp9LNHsRfD1a.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CVS, Oct 30, Build errors on x86_64
Quoting Karl Hegbloom [EMAIL PROTECTED]: On Mon, 2005-10-31 at 09:00 -0500, Josh Sled wrote: On Sun, 2005-10-30 at 23:36 -0800, Karl Hegbloom wrote: I won't have time to try and fix these; I'm way behind on my Mathematics homework and should really be working on that instead... Hope this helps. Do yous have an AMD64 to test compile on? Only vicariously through souls like yourself... :) ...but the issue here isn't x86_64 specific: the GSF_CLASS_FULL macro errors in the lib/goffice/ code are due to a macro signature difference in =libgsf-1.12.1 and =libgsf-1.12.2. Neil Williams had put in a check re: libgoffice / libgsf to work around this on his Debian Unstable box. What system-installed versions of libgsf and libgoffice do you have? libgsf-1-dev 1.12.3-3ubuntu3 libgsf-gnome-1-dev 1.12.3-3ubuntu3 libgoffice-1-dev was not installed at all. I just installed version 0.0.4-1, also from Ubuntu. I don't know how it was able to finish 'configure' and compile as much as it did if it requires libgoffice. Perhaps a 'configure.in' check for that is not present? It probably would fail to link without it. There's an internal version of libgoffice that Gnucash tries to build. Unfortunately it only builds with older libgsf. So you have a too new libgsf but no libgoffice, which is the one part of the matrix that is known to fail. You are correct, there should be a configure switch that fails during configure if it finds a too-new libgsf but no libgoffice. However, it is perfectly legal to build w/o libgoffice installed... -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: G2 Testing
On Mon, 2005-10-31 at 10:44 -0800, Andrew Sackville-West wrote: Also, still no charts. I have tried many different charts with different dates, account selections etc still says: unable to push bar chart -- or -- unable to display pie chart Hmm. Do you have a libgoffice provided by your platform, or the one built in lib/goffice/? Does the Test Graphing report work? If not, what's printed to the console when you try to run it? ...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: CVS, Oct 30, Build errors on x86_64
Quoting Neil Williams [EMAIL PROTECTED]: I still need to update configure.in to prompt for goffice if libgsf-1 = 1.12.2 but it's best to get the G2 branch merged into HEAD and the change to SVN before I go tweaking configure.in again. I see no reason this needs to wait. It's not a large change to configure. -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: src/engine/{qof,gnc}la-dir.h not being built
On Monday 31 October 2005 2:21 pm, Christian Stimming wrote:
Josh Sled wrote:
Noticed during normal upgrade/build cycle (from a cvs update yesterday
evening, which was g2-latest), but I `make distclean`ed, re-autogen and
re-`make install`ed just to be sure...
... src/engine/{qof,gnc}la-dir.h is not being built:
qof.h:99:23: qofla-dir.h: No such file or directory
make[3]: *** [gnc-date.lo] Error 1
qofla-dir.h is not included in the BUILT_SOURCES variable which causes
this problem, I suppose.
Ah, OK.
The Makefile is set up in a way that qofla-dir.h and the whole qof files
will only be built if USE_LIBQOF is true.
Yes, if USE_LIBQOF is false, qofla-dir.h is available via the libqof-dev
package in /usr/include/qof/ and as it is a standard QOF header now, it is
included via qof.h, hence the error if it isn't found with USE_LIBQOF = true.
The variable qof_builds is
supposed to add qofla-dir.h to BUILT_SOURCES... hm... maybe writing
$(qof_builds) instead of ${qof_builds} helps?
I didn't think () vs {} was meant to matter but I do try to use {}.
Or writing
BUILT_SOURCES += qofla-dir.h
Probably better to define a variable that is empty if USE_LIBQOF is false and
contains qofla-dir.h if true. Then add that variable to the existing
BUILT_SOURCES line for both cases. I've had problems with using +=.
Josh - is this problem continuing after you also solved the problem with
gncla-dir.h? It could be an artefact of that problem.
If so (and adding it to BUILT_SOURCES doesn't fix it), I'll look at it and
commit any changes after the CVS-SVN change.
It's partially a result of the vagaries of the gnucash build - in other
programs I simply build the file from AC_OUTPUT in configure - it is then
always available before `make` runs.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgp0xHKcuNpwt.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: src/engine/{qof,gnc}la-dir.h not being built
On Monday 31 October 2005 8:08 pm, Neil Williams wrote: Josh - is this problem continuing after you also solved the problem with gncla-dir.h? It could be an artefact of that problem. Sorry, I meant src/backend/qsf not gncla-dir.h -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgppzEovhJzpW.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Proposal: CVS - SVN switchover: Nov 6th, hopefully
Josh Sled [EMAIL PROTECTED] writes: After coordinating with David Hampton last night, he's hopeful to have the G2 - HEAD merge done by this coming weekend of Nov 5/6th. As such, I intend to do the CVS - SVN repository migration this coming weekend as well. Proposal: On Sunday November 6th we will switch from CVS to SVN. IF YOU HAVE ANY UN-COMMITTED STATE, YOU MAY WANT TO CHECK IT IN ASAP. I have a premonition. This will encounter unexpected hiccups, nothing huge, but problems. Sorting out the problems will take a month. Geez, how hard is it to get the G2 release out the door BEFORE doing this stuff?? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
G2 branch collapse into HEAD
I'm planning to start the g2 branch collapse back into head tomorrow evening at 6PM EST. At that time I will ask Derek to lock the branch so that no further commits can be made. (The HEAD revision of the tree is already locked.) If you have any trivial changes, or outstanding changes that can't wait, please commit them now. Any changes not committed by that time will need to be ported to the new HEAD version by running a 'cvs diff' in your current tree, checking out a new copy of HEAD, and then patching the changes into that new tree. Please respond to the list if this is a problem for anyone, or if I need to postpone the collapse for any reason. Thanks. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CVS, Oct 30, Build errors on x86_64
On Monday 31 October 2005 8:00 pm, Derek Atkins wrote: Quoting Neil Williams [EMAIL PROTECTED]: I still need to update configure.in to prompt for goffice if libgsf-1 = 1.12.2 but it's best to get the G2 branch merged into HEAD and the change to SVN before I go tweaking configure.in again. I see no reason this needs to wait. It's not a large change to configure. No, but it is a change I am unfortunately unable to make in the time before G2 gets locked. My available time for gnucash doesn't come in regular or predictable slots - I have to fit it around other things and the next 24hrs are not available. Sorry. If someone else wants to do it, that's fine by me. Otherwise, I'll work on it on Thursday and commit just as soon as I can. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpLvqCcUWfmn.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Doxygen performance issues
Stewart V. Wright [EMAIL PROTECTED] writes: G'day Neil, * Neil Williams [EMAIL PROTECTED] [051028 16:34]: 1. Our doxygen.cfg.in is out of date compared to Doxygen itself. Running: $ doxygen -u doxygen.cfg.in updates the config file to your currently installed Doxygen version. I really think this relates to the question that was doing the rounds recently (I can't remember the answer) relating to the base release version. Has it been updated to FC 2/3/4 or will the G2 branch remain at RH7.3 ? ;-) We need to ensure that the doxygen version is at most the default version for the base release of the G2 port. G2 release is targetted at FC3/RHEL4 -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
HEAD branch closed in preparation for g2 collapse
In preparation for the G2 branch collapse I have closed the HEAD branch to further commits. Once David is ready to prepare for the collapse we will also close the G2 branch while David performs the branch collapse. We will send out mail prior to the branch closing. Commits should be made on the g2 branch for now, prior to the collapse. -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: Doxygen performance issues
David Hampton [EMAIL PROTECTED] writes: On Fri, 2005-10-28 at 22:32 +0100, Neil Williams wrote: How many of us build the Doxygen HTML regularly? Semi-regularly. I'd hope that doxygen would not update the config in such a way as to make it incompatible with earlier versions but I'm cautious about testing any changes on FC3. Would someone with FC3 be willing to do a before and after time-comparison if I send them a doxygen.cfg.in patch? (And let me know if any config options produce errors like Unknown option in config)? I don't have an FC3 development system, but I can test it on FC4 if you like. I do have an FC3 dev system, so I can test this for you.. However, keep in mind that the CVS/SVN server is running FC1, where the nightly doc build is done... I'm willing to update doxygen to a more recent version if necessary, but just keep that in mind when making changes. I don't plan to update the CVS/SVN machine from FC1 anytime soon. David -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: FW: Re: Doxygen performance issues
Stewart V. Wright [EMAIL PROTECTED] writes: - Forwarded message from Neil Williams [EMAIL PROTECTED] - My FC3 box is running v1.4.4 currently. I notice that the latest release is 1.4.5 Correct. That's what I'm using on Debian unstable. There are number of new options from 1.4.4 to 1.4.5. So is there a consensus in the devs WRT what version of doxygen we are aiming for? G2 release (including docs) is aimed at FC3 == doxygen 1.4.4. -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: Doxygen performance issues
On Monday 31 October 2005 9:31 pm, Derek Atkins wrote: I do have an FC3 dev system, so I can test this for you.. However, keep in mind that the CVS/SVN server is running FC1, where the nightly doc build is done... I'm willing to update doxygen to a more recent version if necessary, but just keep that in mind when making changes. I have now had feedback on the update and any performance problems appear to be due to my relatively underpowered systems - David's machine manages a doxygen build 500% faster than mine. Patching did make that a little faster but the main performance hit seems to be my P3 700MHz. It's just as well that all my other work is on much smaller projects! I don't plan to update the CVS/SVN machine from FC1 anytime soon. That's understandable - I'll leave the doxygen config as is. Any performance gain is likely to be small compared to the actual hardware. I was disappointed that my iBook didn't compare favourably though. It was only a few percentage points better than my P3. :-( Maybe this also explains why rebuilding the gnucash tree from a make distclean every time is such a PITA for me and less of an issue for David! My current bash script to rebuild G2 takes an hour to go from make distclean, through autogen, make, make clean and make install to make dist. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp3HRtW3Y2q5.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Switching from CVS to Subversion: test svn repo available
On Saturday 22 October 2005 11:04 pm, Josh Sled wrote: One thing cvs2svn does /not/ provide (that I can see, anyways) is the migration of the contents of the .cvsignore files into subversion's 'svn:ignore' directory-property. Perhaps someone wants to cut their teeth on subversion by doing this. :) Some content does already exist: $ svn proplist src/backend/qsf/ --verbose Properties on 'src/backend/qsf': svn:ignore : Makefile .deps .libs Makefile.in *.lo *.la qsf-dir.h .DS_Store $ cat src/backend/qsf/.cvsignore Makefile .deps .libs Makefile.in *.lo *.la qsf-dir.h .DS_Store Has this job been done or is it just elements of .cvsignore that have not been converted? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp6PL7PMhflC.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Proposal: CVS - SVN switchover: Nov 6th, hopefully
On Mon, 2005-10-31 at 14:32 -0800, Bill Wohler wrote: Thomas Bushnell BSG [EMAIL PROTECTED] writes: I've either been involved with, or done personally, a couple of CVS to Subversion conversions. Even the large one that affected our entire company went really, really smoothly. As well, a large reason for doing this provisionally last week was to un-un-expect problems. Geez, how hard is it to get the G2 release out the door BEFORE doing this stuff?? If they are more than a month away, chances are that this will have a negligible effect on the date. But there is always a small chance that your premonition comes true ;-) so your point is a good one. I'd guess we're still months away from releasing 2.0. And if you guys are using the SourceForge CVS repository, chances are We're not. - Branch/tag Naming: it seems like a rename [gnucash-1-6-branch - gnucash/branches/1.6] is reasonable. Last-minute objections? That is the normal method. I'd also expect to see gnucash/tags/1.8.12 and HEAD in gnucash/trunk. Ah, Bill, you might not have seen http://lists.gnucash.org/pipermail/gnucash-devel/2005-October/014333.html which has details about the repository layout and the question re: renaming. ...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: Switching from CVS to Subversion: test svn repo available
On Saturday 22 October 2005 11:04 pm, Josh Sled wrote: svn.gnucash.org is setup and resolves (thanks Linas! :), so the various base URLs look like: anonymous: http://svn.gnucash.org/repo/gnucash/trunk developer: svn+ssh://svn.gnucash.org/repo/gnucash/trunk Josh, should I have access under the developer URL? $ svn checkout http://svn.gnucash.org/repo/gnucash/trunk gnucash Works (I've only tested with gnucash-gnome2-dev branch) $ svn checkout svn+ssh://svn.gnucash.org/repo/gnucash/branches/gnucash-gnome2-dev gnome2 Permission denied (publickey,keyboard-interactive). svn: Connection closed unexpectedly Failed. PLEASE checkout and play around with this provisional repository. If you're a dev, then PLEASE make some changes and check them in. Try to explore the history to make sure it's all there. Create a branch, rename some files, c. I want to experiment with a cashutil branch but I haven't had time since your email due to other commitments. Please let me (and the list) know if there are any configuration issues or problems. I'll be traveling next week, but will be checking mail periodically and certainly when I get back. Do you need my SSH public key? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpQ4akQkRbcx.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Switching from CVS to Subversion: test svn repo available
On Mon, 2005-10-31 at 22:50 +, Neil Williams wrote: Josh, should I have access under the developer URL? Yes. If you can use cvs, then you should be able to use svn+ssh ... it's the same mechanism used to invoke both. $ svn checkout svn+ssh://svn.gnucash.org/repo/gnucash/branches/gnucash-gnome2-dev gnome2 Permission denied (publickey,keyboard-interactive). svn: Connection closed unexpectedly Failed. You may need to use `svn co svn+ssh://[EMAIL PROTECTED]/[...]` to change the user being ssh-authenticated. ...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: Proposal: CVS - SVN switchover: Nov 6th, hopefully
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Josh Sled [EMAIL PROTECTED] writes: After coordinating with David Hampton last night, he's hopeful to have the G2 - HEAD merge done by this coming weekend of Nov 5/6th. As such, I intend to do the CVS - SVN repository migration this coming weekend as well. Proposal: On Sunday November 6th we will switch from CVS to SVN. IF YOU HAVE ANY UN-COMMITTED STATE, YOU MAY WANT TO CHECK IT IN ASAP. I have a premonition. This will encounter unexpected hiccups, nothing huge, but problems. Sorting out the problems will take a month. I've either been involved with, or done personally, a couple of CVS to Subversion conversions. Even the large one that affected our entire company went really, really smoothly. Geez, how hard is it to get the G2 release out the door BEFORE doing this stuff?? If they are more than a month away, chances are that this will have a negligible effect on the date. But there is always a small chance that your premonition comes true ;-) so your point is a good one. And if you guys are using the SourceForge CVS repository, chances are you can get the SourceForge team to do it for you really soon or pretty soon: https://sourceforge.net/tracker/index.php?func=detailaid=1341005group_id=1atid=350001 - Branch/tag Naming: it seems like a rename [gnucash-1-6-branch - gnucash/branches/1.6] is reasonable. Last-minute objections? That is the normal method. I'd also expect to see gnucash/tags/1.8.12 and HEAD in gnucash/trunk. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Switching from CVS to Subversion: test svn repo available
On Monday 31 October 2005 11:01 pm, Josh Sled wrote: On Mon, 2005-10-31 at 22:50 +, Neil Williams wrote: Josh, should I have access under the developer URL? You may need to use `svn co svn+ssh://[EMAIL PROTECTED]/[...]` to change the user being ssh-authenticated. Doh! Working now. Thanks Josh. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpUkvuKFLYCJ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r11623 - in gnucash/branches/cashutil/cashutil: . debian doc doc/man doc/xml website website/images - ancillary cashutil files [temp]
Neil, You DO realize that the SVN repository is going to be destroyed this weekend, right? Just wanted to make sure you're not expecting these commits to actualy stay... Because they wont. The current repo is a complete test repo and will be destroyed and recreated when the CVS-SVN migration happens this coming weekend. -derek Quoting Neil Williams [EMAIL PROTECTED]: Author: codehelp Date: 2005-10-31 18:47:32 -0500 (Mon, 31 Oct 2005) New Revision: 11623 Added: gnucash/branches/cashutil/cashutil/debian/cashutil.dirs gnucash/branches/cashutil/cashutil/debian/cashutil.install gnucash/branches/cashutil/cashutil/debian/changelog gnucash/branches/cashutil/cashutil/debian/compat gnucash/branches/cashutil/cashutil/debian/control gnucash/branches/cashutil/cashutil/debian/copyright -- 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
G2 testing : lock up while NOT saving file
I have experienced a lock-up of gnucash. I was playing with one of my test files and decided to open another file. Selected File - Open - Open... . Pop-up dialog says I have not saved changes, would you like to (working from memory here). I click NO. That pop-up dialog blanks out, but remains on the screen and gnucash is lock-up. there is no gnucash in top or ps -e. there is however guile. terminal says: [EMAIL PROTECTED]:~$ /opt/gnc2/bin/gnucash This is a development version. It may or may not work. Report bugs and other problems to [EMAIL PROTECTED] You can also lookup and file bug reports at http://bugzilla.gnome.org The last stable version was GnuCash 1.8.12 The next stable version will be GnuCash 2.0 initializing gnc_html... gnucash: [W] failure loading /home/andrew/.gnucash/config-1.8.auto gnucash: [W] report-menu-setup Use of deprecated SAXv1 function getLineNumber *** glibc detected *** realloc(): invalid next size: 0xb6213c88 *** plugin not loadedplugin not loadedplugin not loadedplugin not loadedplugin not loadedplugin not loadedplugin not loadedplugin not loaded this is the total output from starting the program to crash. I have successfully replicated it once, but now it will not happen for me again I opened the file, which had an Income Statement report already open in the saved version. SO I had just the accounts and the report up. Then open three registers from the report (see other thread about window size creep) then as before File - Open - Open... click NO and then (second time through here) I got this: [EMAIL PROTECTED]:~$ /opt/gnc2/bin/gnucash This is a development version. It may or may not work. Report bugs and other problems to [EMAIL PROTECTED] You can also lookup and file bug reports at http://bugzilla.gnome.org The last stable version was GnuCash 1.8.12 The next stable version will be GnuCash 2.0 initializing gnc_html... gnucash: [W] failure loading /home/andrew/.gnucash/config-1.8.auto gnucash: [W] report-menu-setup Use of deprecated SAXv1 function getLineNumber Multiple segmentation faults occurred; can't display error dialog I did however display an error dialog asking if I wanted to inform you all ;). This brings up bug boddy which didn't seem to be any help. no stack. I'll try to reproduce it again, but its not working at the moment. Well, I guess that means it is working? ;) oh yeah. CVS 10/30 in afternoon (PST). A ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
E-guile link
FYI, the e-guile link is back up: http://woozle.org/~neale/repos/eguile/eguile.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: Mailing List Options [was Re: Switching...]
On Sun, 2005-10-30 at 18:56 -0500, Chris Shoemaker wrote: There should be only 2 lists: -users and -devel. Reasoning: X -patches should go to -devel. * All submitted patches should be up for discussion. * It's hard to know before hand what patches actually will generate discussion. * It's hard to move the thread after-the-fact. * Anyone willing to subscribe to -devel *should* be willing to see the trafic that -patches would get. X -changes should go to -devel. * Any commited change might generate discussion. * Again, hard to know before; hard to move after. * Again, anyone on -devel should be willing to see commits. X -commits should go to /dev/null. * There are better ways to syndicate the commit log than a mailing list. * But, if there *has* to be a place for emails of the commit log, it shouldn't be the same list where the full diffs go. Not being a developer per se, but nevertheless involved with the process, if the above happened I would more than likely unsubscribe from the -devel list and no doubt be inclined to not have any more involvement with GnuCash. There's no reason imho that patches and changes should clutter up the discussion on that list. Chris -- RedHat Certified Engineer #807302549405490. Checkpoint Certified Security Expert 2000 NG |^| | | |^| | |^| | | Life out here is raw | | |^| | But we will never stop | |_|_| | We will never quit | / __ | cause we are Metallica |/ /| \ / | | ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing - gconf Druid
I rebuild my copy of GnuCash today and I'm retesting the gconf druid: When I start gnucash a message window comes up (Cannot find default values). The Help button is highlighted by default but there is no help when pressed (maybe I need to install documentation files separately?). The Setup button is now the default. OK. On the window titled Choose Method the focus sometimes disappears when cycling through the options with the TAB key. Update Search Path -- blank -- blank -- Cancel -- Back -- Forward -- blank -- Update Search Path -- ... Fixed. Tab order is OK. However, when selecting the Forward button for the first time from the Choose Method window with the option Update search path selected, the window size of the next window titled Update Search Path is slightly larger then the previous window (about 5 - 10 pixels). Moving back and forth between these two windows afterwards does not change the window size any more. Also, the window size does not change when moving to the Install into home directory window when pressing the Forward button the first time around. By the way, shouldn't the window titles Install into home directory and Update search path be capitalized? I'm just wondering. Everything works when the Update Search Path option is selected. However, when selecting the option I'll do it myself on the following window the last window gives the instructions to edit the .gconf.path file and restart the gconf backend. There is no mention on how to restart the gconf backend. I suggest to list the command gconftool-2 --shutdown here. Or maybe better let the user know on the previous window (Update Path) that the gconf backend will need to be restarted if the .gconf.path file got modified. With that information users might rather want gnucash to do this for them. I've done both of these. Great! This is much better now and easy to follow. There is one issue I can foresee though: The option of the command gconftool-2 --shutdown appears - due to the font - to be just a single dash '-' instead of two dash '--'. Maybe it's possible to add an extra space between those dashes or to display the command in a fixed type font to make it more obvious? When the option Install into home directory is selected the option Do it for me on the next window fails. So does the I'll do it myself since the shell script update-gnucash-gconf is not in the default search path. Note: I have gnucash installed under /opt/gnucash2 The update-gnucash-gconf script is installed in the same directory as gnucash. Please try again with /opt/gnucash2/bin (or wherever) in your search path. Both of these cases should work with the path set. I've also added a note to the text that this file must appear in your search path. I couldn't find the note in the druid indicating that the file must appear in the search path when selecting I'll do it myself. Other then that the instructions are easy to follow now and everything works as expected. -- Thanks Volker Englisch mailto:[EMAIL PROTECTED](h) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Adding a Payroll calculator
On Mon, 2005-10-31 at 10:16 -0800, Andrew Sackville-West wrote:
IMHO, based on the broad requirements of many jurisdictions in the
gnucash user base, the more generic the solution the better. I
suppose
that at some point it becomes no easier than using a spreadsheet, but
bypasses the importing requirements of that solution.
In my past thoughts on this, it seemed reasonable to come up with a
handful of different classes of payroll items with all the numbers
(tax
percentages, wage bases, etc) applied directly by the user. Ummm..
sort
of like setting up tax tables. Create a table, assign a name and a
variety of features for that particular instance and save it. Then
apply
the appropriate items to each employee as they are created/edited. Is
this what you are getting at? Each employee record would point to
its
payroll record and have any number of fields for various requirements
(wage, taxes, deductions, etc). Some of the fields could have a
prompt
flag that would prompt the user for this information at the time
payroll
is executed. Obvious one would be hours worked, but other could be
reported tips or reimbursements. IIRC I had narrowed this down to
just a handle of classes to get most thigns to work. (My knowledge of
gnucash code is - 0 and my coding is rusty - infinity so my
vocabulary
above is probably wrong ;) ).
When you process the payroll, at the point that you execute the
payroll,
the pertinent information is calculated and then stored in the
payroll
transaction (probably in the memo and description fields).
Am I following you correctly? are we talking about the same thing?
A
Right on target. I my self don't know yet how GnuCash stores the
information into each account. But it would be nice if there was a form
to fill out while performing payroll that resembled a time clock or
pay-stub format (Once hours were entered all the calculations are
preformed).
Of course the other options would include strait salaries and
commissions. But these would be definable at the time of employee
Creation/Hire.
There are two major occurrences of payroll calculation.
1: performing the actual paycheck calculation.
2: Then reporting the totals for the quarterly tax return.
Payroll taxes could be members of the Tax class and still be different
from regular sales and income taxes. However Payroll taxes for the us
will be accounted on a quarterly basis with the IRS form 941.
I myself am very rusty on c but here's a shot. And I haven't the
experience with any GUI's except Perl::Tk and html.
I have used Derek Atkins's _gncEmployee class as a template for this
Example:
struct _gncTax
{
char * id;
char * taxName; /* Medicare, SSI, Sales,..etc */
char * taxType; /* Payroll, Payroll, Sales */
char * taxCatagory;/* Employee, Salary, Sale */
gnc_numeric taxRate; /* .0145, .062, .893 */
gnc_numeric taxFrequency; /* hourly, monthly, unit */
gnc_commodity * currency;
gbooleanactive;
char * language;
Account * tax_acc;
};
Jay Scherrer
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
