Re: Adding a Payroll calculator
On Sat, 2005-10-29 at 22:48 -0700, Jay Scherrer wrote: bits snipped 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). 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). 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. Conrad. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
On Sunday 30 October 2005 2:44 am, Brian Rose wrote: Hmm, I was hoping it would be possible to use Gnucash via the desktop for one user and via a webpage for another user simultaneously--maybe that is a longer way off than I thought. None of the current developers have shown an inclination to work on such a feature so it will remain a long way off until someone decides it is worth investigating. It is a lot more complex than you may envisage - mainly because of the implicit logic that is hard to replicate in a browser environment. You'd need something compiled on the server that could do the job, maybe a new perl module that wraps a new C library or the proposed logic library required for cashutil. Well, the site explains the theory pretty well. However, I am throwing out ideas for consideration to make Gnucash tasty to an enduser/small business owner who isn't a Linux guy--e.g., avoids the command-line and doesn't want to code. I suggest you look at QSF and maybe help me finish off the conversion routines and invoice export. 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. 2. Someone else will undoubtedly have yet another target that should be considered. 3. QSF *can* deal with ANY external customisation requests. By having just the data required, you can develop a simple Perl/Python/PHP/whatever process that parses the XML and produces the template / report / format you need for whatever your target may be. It's designed to be all things to all men and once a conversion script is created, it remains current because all that is changing is the internal data - not the QSF format itself. Highly flexible, but using a GUI and a template creator. If it's flexible enough to import data into that template, QSF can provide the data. It's just a question of a suitable script to process the output. Are you happier in GUI development or CLI or both? Web dev and backend stuff is where I am most comfortable. Sounds perfect. Backend stuff will be the invoice QSF which still needs a few tweaks in src/business/business-core/gncInvoice.c and src/backend/qsf/qsf-backend.c - contact me off-list if you'd like to look into that and I can send you some examples. Web dev stuff is really down to your preference of Perl, PHP, Python, XQuery, XPath or something else to parse the XML and output the data in a format suitable for your template. Well, I am not sure other than above on invoices and what others have mentioned in this thread. Fine, that's enough for now. It's how I started too. My primary purpose is speaking up is because I want to help enable more productivity and more small business users and hence a better, stronger Gnucash. In which case, you will be very welcome here. Derek mentioned that there were enough web programmers. Is there a need for people to port documentation from the dev list and doxygen to the web to help enable new programmers with Gnucash to be productive more quickly? Yes - the only question is WHERE that documentation should be hosted. I've had to host my own (http://code.neil.williamsleesmill.me.uk/) because access to the gnucash site is so limited. I do have space there to host some more but I'd have to arrange some form of access until I get time to put Drupal onto that box. What I think we need is: 1. Entry-level docs that fill the gap between the detailed doxygen output, the patchy related pages docs - some of which are quite outdated - and the current gnucash website. 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. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpsXLAkWVvwY.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Conclusion about CVS to Subversion et al. discussion
I think it's about time to conclude this version control discussion for now, make a decision based on the current consensus, postpone further discussion into next year, and continue coding on the gnome2 port for now. From what we can see in the -devel and -patches discussion, everyone agrees that we should make a transition from CVS to a more modern version control system. Also, everyone would agree that SVN is in fact such a more modern version control system. Josh's test setup for the gnucash repository on SVN works already quite nice and gives a good impression of the benefits from SVN (like, svn diff for the full commit of one person at one time, or in other words: the full changeset can be viewed easily). There is no general agreement on whether a dedicated SCM like git would offer enough additional benefit so that a transition of the gnucash repository to such an SCM would be a good decision at this point in time. (For example, I tend to agree that there is enough additional benefit in such a move, but as I said, there is no general agreement.) I would therefore propose that we decide on the transition to Subversion *now*, and that this transition should happen in the next 1-2 weeks. @David Hampton: Would you suggest to do the gnome2-branch merging to HEAD still in CVS, and make the transition to SVN after that? Or would you suggest that we can make the SVN-transition with the current repository, so that the gnome2-branch merging to HEAD will be done in SVN? If the former, then I would kindly ask whether the gnome2-HEAD merge could be done ASAP; if the latter, I would suggest that the transition to SVN should be done in the next 1-2 weeks. Additionally, I would propose that we stop the discussion of the SCM issue now and reconsider this again at a later point in time (e.g., in six months from now), when we can already see whether some of the source control issues are already resolved by using SVN instead of CVS. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
Quoting Neil Williams [EMAIL PROTECTED]: Derek mentioned that there were enough web programmers. Is there a need for people to port documentation from the dev list and doxygen to the web to help enable new programmers with Gnucash to be productive more quickly? Yes - the only question is WHERE that documentation should be hosted. I've had to host my own (http://code.neil.williamsleesmill.me.uk/) because access to the gnucash site is so limited. I do have space there to host some more but I'd have to arrange some form of access until I get time to put Drupal onto that box. The only reason you've had to do that is because I've only run the doxygen docs on HEAD, not g2. Once g2-HEAD then you'll no longer need to do that for doxygen. -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
autogen.sh stops when trying cvs g2 build...
Hi, perhaps I've missed something important, but I don't know what ;-) If I try to build a g2 CVS version, then autogen.sh stops with the message, that there is no Makefile.in :-( Any hints?? Where is my error? I've done a cvs update -C before the autogen.sh run. Hope you can help me Micha Here is the output: processing . deletefiles is *** WARNING *** *** We're about to run gettext which may spew a few paragraphs *** of crap at you and ask you to acknowledge it. If it does this, *** just hit return to acknowledge gettext. You DO NOT need to do *** anything that it asks of you except hitting return. Creating ./aclocal.m4 ... (3) Running gettextize... Ignore non-fatal messages. Copying file mkinstalldirs Copying file po/Makefile.in.in Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /usr/share/aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/. Making ./aclocal.m4 writable ... Running intltoolize ... You should update your 'aclocal.m4' by running aclocal. no need for patching file 'Makefile.in.in' Running libtoolize... Running aclocal -I ./macros ... /usr/share/aclocal/oaf.m4:4: warning: underquoted definition of AM_PATH_OAF run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/share/aclocal/libguppi.m4:11: warning: underquoted definition of AM_PATH_LIBGUPPI /usr/share/aclocal/libglade.m4:7: warning: underquoted definition of AM_PATH_LIBGLADE /usr/share/aclocal/gdk-pixbuf.m4:12: warning: underquoted definition of AM_PATH_GDK_PIXBUF /usr/share/aclocal/gconf-1.m4:4: warning: underquoted definition of AM_PATH_GCONF /usr/share/aclocal/gconf-1.m4:71: warning: underquoted definition of AM_GCONF_SOURCE /usr/share/aclocal/g-wrap.m4:7: warning: underquoted definition of AC_GWRAP_CHECK_GUILE /usr/share/aclocal/g-wrap.m4:23: warning: underquoted definition of AM_PATH_GWRAP Running autoheader... Running automake --gnu ... lib/Makefile.am:4: required directory lib/glib26 does not exist lib/Makefile.am:2: required directory lib/glib26 does not exist src/import-export/Makefile.am:1: required directory src/import-export/schemas does not exist src/import-export/Makefile.am:2: required directory src/import-export/schemas does not exist configure.in:1425: required file `lib/glib26/Makefile.in' not found configure.in:1425: required file `src/import-export/schemas/Makefile.in' not found /usr/share/automake-1.9/am/tags.am: ctags was already defined in condition !GNC_CTAGS_FILE, which is included in condition TRUE ... Makefile.am:119: ... `ctags' previously defined here Running autoconf ... Running ./configure --enable-maintainer-mode --enable-error-on-warning --enable-compile-warnings --prefix=/develop/gnucash/bin/gnucash-g2-bla --enable-opt-style-install --enable-hbci ... checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for perl... /usr/bin/perl checking for XML::Parser... ok checking for iconv... /usr/bin/iconv checking for msgfmt... /usr/bin/msgfmt checking for msgmerge... /usr/bin/msgmerge checking for xgettext... /usr/bin/xgettext Using config source xml::/etc/gconf/gconf.xml.defaults for schema installation Using $(sysconfdir)/gconf/schemas as install directory for schema files checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for ngettext in libc... yes checking for dgettext in libc... yes checking for bind_textdomain_codeset... yes checking for msgfmt... /usr/bin/msgfmt checking for dcgettext... yes checking for gmsgfmt... /usr/bin/gmsgfmt checking for xgettext... /usr/bin/xgettext checking for catalogs to be installed... da de el en_GB es
Re: GnuCash design / new features
On Sunday 30 October 2005 1:24 pm, Derek Atkins wrote: Quoting Neil Williams [EMAIL PROTECTED]: Derek mentioned that there were enough web programmers. Is there a need for people to port documentation from the dev list and doxygen to the web to help enable new programmers with Gnucash to be productive more quickly? Yes - the only question is WHERE that documentation should be hosted. I've had to host my own (http://code.neil.williamsleesmill.me.uk/) because access to the gnucash site is so limited. I do have space there to host some more but I'd have to arrange some form of access until I get time to put Drupal onto that box. The only reason you've had to do that is because I've only run the doxygen docs on HEAD, not g2. Once g2-HEAD then you'll no longer need to do that for doxygen. True, however I was thinking of my other documentation on that server. The URL itself goes to the DocBook documentation I wrote for qof_book_merge and QSF rather than the G2 Doxygen output. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpdPdLH4hc3U.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 1:48 pm, Michael Wahlbrink wrote: Hi, perhaps I've missed something important, but I don't know what ;-) It looks (to me) like you have a mixed 1.8 and G2 tree (somehow). If I try to build a g2 CVS version, then autogen.sh stops with the message, that there is no Makefile.in :-( Any hints?? Where is my error? I've done a cvs update -C before the autogen.sh run. /usr/share/aclocal/libguppi.m4:11: warning: underquoted definition of AM_PATH_LIBGUPPI Guppi was 1.8 only - if you aren't building HEAD or running gnucash 1.8 anymore, remove Guppi. lib/Makefile.am:4: required directory lib/glib26 does not exist lib/Makefile.am:2: required directory lib/glib26 does not exist Check why that has happened. lib/glib26 should have been created in the CVS checkout. What CVS command did you use? src/import-export/Makefile.am:1: required directory src/import-export/schemas does not exist src/import-export/Makefile.am:2: required directory src/import-export/schemas does not exist This looks like a badly corrupted tree but I can't understand what you did to not get these directories created. checking for GLIB - version = 2.4.0... yes (version 2.6.5) checking for GLIB - version = 2.6.0... yes So this, at least, is a G2 configure that is being run. No package 'qof-1' found no, will use internal QOF code checking for GOffice and GSF... No, GOffice not found, will build using internal goffice library. These are fine - G2 is designed to build with internal versions of these two if they are not already installed. configure: creating ./config.status config.status: creating po/Makefile.in config.status: creating Makefile config.status: error: cannot find input file: Makefile.in As with all such situations, the last error message is rarely important - it is usually just a consequence of earlier errors. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpTo9Um4OUoC.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...
Hi, Neil Williams schrieb: On Sunday 30 October 2005 1:48 pm, Michael Wahlbrink wrote: Hi, perhaps I've missed something important, but I don't know what ;-) It looks (to me) like you have a mixed 1.8 and G2 tree (somehow). It was a about 2month old g2 chackout, which I've updated today. If I try to build a g2 CVS version, then autogen.sh stops with the message, that there is no Makefile.in :-( Any hints?? Where is my error? I've done a cvs update -C before the autogen.sh run. /usr/share/aclocal/libguppi.m4:11: warning: underquoted definition of AM_PATH_LIBGUPPI Guppi was 1.8 only - if you aren't building HEAD or running gnucash 1.8 anymore, remove Guppi. The guppi is from the working gnome 1 gnucash of the distro (gentoo) I use this gnucash for my daily business If it important to remove it, I will setup a chroot for testing gnucash g2! lib/Makefile.am:4: required directory lib/glib26 does not exist lib/Makefile.am:2: required directory lib/glib26 does not exist Check why that has happened. lib/glib26 should have been created in the CVS checkout. What CVS command did you use? src/import-export/Makefile.am:1: required directory src/import-export/schemas does not exist src/import-export/Makefile.am:2: required directory src/import-export/schemas does not exist This looks like a badly corrupted tree but I can't understand what you did to not get these directories created. checking for GLIB - version = 2.4.0... yes (version 2.6.5) checking for GLIB - version = 2.6.0... yes So this, at least, is a G2 configure that is being run. No package 'qof-1' found no, will use internal QOF code checking for GOffice and GSF... No, GOffice not found, will build using internal goffice library. These are fine - G2 is designed to build with internal versions of these two if they are not already installed. configure: creating ./config.status config.status: creating po/Makefile.in config.status: creating Makefile config.status: error: cannot find input file: Makefile.in As with all such situations, the last error message is rarely important - it is usually just a consequence of earlier errors. Ok Ok, I will try to do a fresh checkout an test then again Thanks Micha ___ 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...
Quoting Michael Wahlbrink [EMAIL PROTECTED]: It was a about 2month old g2 chackout, which I've updated today. How did you update? You probably didn't use the CVS Command to pull out new directories. Generally you need cvs -q up -Pd to make sure you pull out new directories (and delete empty ones). I suspect you just did a cvs update. /usr/share/aclocal/libguppi.m4:11: warning: underquoted definition of AM_PATH_LIBGUPPI Guppi was 1.8 only - if you aren't building HEAD or running gnucash 1.8 anymore, remove Guppi. The guppi is from the working gnome 1 gnucash of the distro (gentoo) I use this gnucash for my daily business If it important to remove it, I will setup a chroot for testing gnucash g2! This is just a warning that you can safely ignore. lib/Makefile.am:4: required directory lib/glib26 does not exist lib/Makefile.am:2: required directory lib/glib26 does not exist THIS implies you don't have the full source tree -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: GnuCash design / new features
Quoting Neil Williams [EMAIL PROTECTED]: True, however I was thinking of my other documentation on that server. The URL itself goes to the DocBook documentation I wrote for qof_book_merge and QSF rather than the G2 Doxygen output. Just a side question... is there any particular reason the qof_book_merge docs aren't in doxygen? I can somewhat understand why QSF docs aren't. -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: GnuCash design / new features
On Sunday 30 October 2005 3:18 pm, Derek Atkins wrote: Quoting Neil Williams [EMAIL PROTECTED]: True, however I was thinking of my other documentation on that server. The URL itself goes to the DocBook documentation I wrote for qof_book_merge and QSF rather than the G2 Doxygen output. Just a side question... is there any particular reason the qof_book_merge docs aren't in doxygen? I can somewhat understand why QSF docs aren't. The qof_book_merge API is in Doxygen - lots and lots of it. The stuff on my own server is more the design behind the API along with links to a whole range of other documentation. I suppose it's grown beyond the qof_book_merge name really but I have now subtitled it: Query Object Framework: Design and direction. to give a hint that it's more than just the merge. http://code.neil.williamsleesmill.me.uk/ The index (including some pages that just link to other sites or documentation generated from other projects) covers: Preface 1. QOF dependencies. 2. GnuCash dependencies. 2.1. GnuCash for Gnome2: gnucash-gnome2-dev 2.2. Building GnuCash 1. Introduction 1.1. Terms and definitions. 1.1.1. QOF: Query Object Framework . 1.1.2. Pilot-QOF: Querying Palm databases as objects. 1.1.3. QOF-gen: QOF Object Generator. 1.1.4. Data Freedom: Liberate your data from the application. 1.1.5. What's a QofBook? 1.1.6. QSF - QOF Serialization Format. 1.2. Other versions of this documentation. 2. Background 3. Source Documentation 3.1. Doxygen Documentation. 3.1.1. qof_book_merge Doxygen documentation. 3.1.2. QSF Doxygen documentation. 3.1.3. QOF Doxygen documentation. 3.1.4. GnuCash Doxygen documentation. 3.1.5. GnuCash Gnome2 port Doxygen documentation. 3.2. Other general documentation 3.2.1. Gnucash Design documentation 3.2.2. GnuCash Tutorial and Concepts Guide 3.2.3. GnuCash Help Manual 3.2.4. KVP Values used By GnuCash 3.3. qof_book_merge Source Code 3.4. QSF Source code 3.4.1. QSF and qof_book_merge tarballs 4. Creating GnuCash Invoices using a Palm PDA 4.1. Beginnings 4.2. Getting into GnuCash / QOF 4.2.1. Why the GnuCash File QofBackend needs changing 4.2.2. Tips on debugging within GnuCash 4.3. Building QOF onto pilot-link 4.3.1. Converting existing objects to QOF 4.4. Pilot-QOF 4.4.1. What does QOF have to do with pilot-link, or vice versa? 4.4.2. pilot-qof manpages 4.4.3. Generating new objects 5. QSF - QOF Serialization Format. 5.1. What is QSF? 5.1.1. Features of QSF 5.1.2. Requirements of QSF 5.1.3. Validation of QSF. 5.1.4. QSF examples 5.2. Mapping QSF objects between QOF applications 5.2.1. The QSF Map file 5.2.2. Relating the map to the QSF objects 5.3. Writing new QSF maps 6. Merging QofBook's 6.1. Preparing the rule set 6.2. Draft of a rule set framework. 6.3. Design of the merge 6.3.1. Example programs for qof_book_merge 6.4. Using qof_book_merge with new and existing QOF objects 6.5. Known problems 6.6. Design improvements 7. Data Mining and freedom of access. 7.1. Data mining within QOF 7.2. Data Freedom within QOF I think I've got the split about right - maybe there is still too much in the Doxygen output but there are topics covered at my own site that simply don't fit into gnucash or QOF doxygen. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpC3yQqmR19w.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...
Derek Atkins schrieb: Quoting Michael Wahlbrink [EMAIL PROTECTED]: It was a about 2month old g2 chackout, which I've updated today. How did you update? You probably didn't use the CVS Command to pull out new directories. Generally you need cvs -q up -Pd to make sure you pull out new directories (and delete empty ones). I suspect you just did a cvs update. U, yeah I think that this might be the error.. Ok I try to update with your command (I'm not so familiar with CVS, I'm a SVN user ;-) ) /usr/share/aclocal/libguppi.m4:11: warning: underquoted definition of AM_PATH_LIBGUPPI Guppi was 1.8 only - if you aren't building HEAD or running gnucash 1.8 anymore, remove Guppi. The guppi is from the working gnome 1 gnucash of the distro (gentoo) I use this gnucash for my daily business If it important to remove it, I will setup a chroot for testing gnucash g2! This is just a warning that you can safely ignore. Ok, so I can continue to use both versions on the same system ;-) lib/Makefile.am:4: required directory lib/glib26 does not exist lib/Makefile.am:2: required directory lib/glib26 does not exist THIS implies you don't have the full source tree see above It seems there've been some changes during the last few months ;-) -derek thanks for the help micha ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing - Gnucash Preferences
David Hampton wrote: The default value for Register lines is set to 2. I think this value should be increased to display at least 3 lines in the Scheduled Transaction Editor. I see this as a default of 6 lines in the code. If you remove the ~/.gconf/apps/gnucash directory, restart gconf with 'gconftool-2 --shutdown', and then start gnucash do you still see a value of 2? I did this and found out that the default is actually set to '1' on my build. It must have already been updated since I build/updated my copy of GC last time. I'll create a new build soon and will then retest this the and the gconf druid as well. While I was looking at this I noticed something else. When you enter a split with the same Memo as the previous split the account is populated when tabbing to the account field. However, the account is not an existing account at all. It's just an account ID. I searched my data file for the account ID displayed but I couldn't find it. Sample: http://www.englisch.us/~volker/G2_Testing/SXAccount.jpg -- Thanks Volker Englisch mailto:[EMAIL PROTECTED](h) ___ 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
Sorry for answering late to this email. I was traveling last week, and was away from my email... My comment is just about the following specific point: [...] I've setup the post-commit hook to mail the changeset diffs to '[EMAIL PROTECTED]'. Note that a seperate gnucash-patches mail of only the commit notice (without diffs) is *not* setup here. I'm not sure that it will be, either. If you have a strong desire to have a non-diff-containing-per-commit email, speak up now. I've always wondered why the commits are systematically sent to gnucash-patches... This results in noise and an additional chance to forget or loose patches (since no dedicated tool exists to manage them). Why not just sending the patches, the patches acknowledgments and the patches commits to gnucash-patches ? Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash design / new features
On Sun, 2005-10-30 at 09:53 +, Neil Williams wrote: On Sunday 30 October 2005 2:44 am, Brian Rose wrote: Hmm, I was hoping it would be possible to use Gnucash via the desktop for one user and via a webpage for another user simultaneously--maybe that is a longer way off than I thought. None of the current developers have shown an inclination to work on such a feature so it will remain a long way off until someone decides it is worth Actually, you and warlord have both said this recently, and I just wanted to say that I *do* want to do this, actually. But it's sufficiently far enough out on my todo list (1 year, at least) as to practically be useless. :) ...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 Sun, 2005-10-30 at 20:01 +0100, Didier Vidal wrote: I've always wondered why the commits are systematically sent to gnucash-patches... This results in noise and an additional chance to forget or loose patches (since no dedicated tool exists to manage them). Why not just sending the patches, the patches acknowledgments and the patches commits to gnucash-patches ? I guess there's an argument for minimizing mailing-list management... but I could certainly see having 3 lists: - gnucash-patches (manual patch submission + ack + discuss) - gnucash-changes (commit notification, w/ diffs) - gnucash-commits (commit notification, w/o diffs) Or, optionally, only the first 2. ...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
Josh Sled wrote: On Tue, Oct 25, 2005 at 06:50:36PM -0400, Derek Atkins wrote: | |Something like | |http://www.goshaky.com/goshaky-distfiles/svn2rss/ | |might be useful once SVN is in use - and rss feed of svn commits. | | I have no objection to this, but I don't see why it would be useful to | anyone when gnucash-changes exists... RSS feeds are quite useful in their own ways Wouldn't be too hard to cook up a script that shows an RSS feed of the last n posts to gnucash-changes In fact, I couldn't resist: http://bzzt.net/cgi-bin/gnucash-changes.cgi ;) Kind regards, Arnout ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
FW: Re: Doxygen performance issues
- 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? You haven't tried to build cd src/doc/ make doc yet? Yup, didn't take too long and didn't crash my machine. You must have a REALLY underpowered setup! ;-) I have timeed a make doc and from a clean autogen.sh run on my directory, I get the following... real1m53.387s user1m31.535s sys 0m5.951s I'm really surprised you are having problems with doxygen, I honestly don't see anything that is vaguely necessitating any changes. By that I mean make doc is relatively fast and there are no obvious errors. Are you sure you haven't done something to cause your doxygen to play up? Patch for src/doc/doxygen.cfg.in is attached. I'll apply it when it becomes clear to me what version of doxygen we/you/the collective will of the devs are talking about. Cheers, S. pgpBqggpsnzrP.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
src/engine/{qof,gnc}la-dir.h not being built
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:
make[3]: Entering directory
`/home/jsled/stuff/proj/gnucash/src-g2/gnucash/src/engine'
source='gnc-date.c' object='gnc-date.lo' libtool=yes \
depfile='.deps/gnc-date.Plo' tmpdepfile='.deps/gnc-date.TPlo' \
depmode=gcc3 /bin/sh ../../depcomp \
/bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../..
-I../../lib/libc -I../../src/core-utils -I../../src -I../../src/gnc-module
-I../../src/business/business-core/ -I../../src/engine -DGNUCASH -pthread
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I /usr/include/g-wrap
-O3 -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Werror -c
-o gnc-date.lo `test -f 'gnc-date.c' || echo './'`gnc-date.c
mkdir .libs
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/libc -I../../src/core-utils
-I../../src -I../../src/gnc-module -I../../src/business/business-core/
-I../../src/engine -DGNUCASH -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I /usr/include/g-wrap -O3 -g -Wall -Wunused
-Wmissing-prototypes -Wmissing-declarations -Werror -c gnc-date.c -MT
gnc-date.lo -MD -MP -MF .deps/gnc-date.TPlo -fPIC -DPIC -o .libs/gnc-date.o
In file included from gnc-trace.h:40,
from gnc-date.c:45:
qof.h:99:23: qofla-dir.h: No such file or directory
make[3]: *** [gnc-date.lo] Error 1
[...deletia...]
source='gnc-engine.c' object='gnc-engine.lo' libtool=yes \
depfile='.deps/gnc-engine.Plo' tmpdepfile='.deps/gnc-engine.TPlo' \
depmode=gcc3 /bin/sh ../../depcomp \
/bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../..
-I../../lib/libc -I../../src/core-utils -I../../src -I../../src/gnc-module
-I../../src/business/business-core/ -I../../src/engine -DGNUCASH -pthread
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I /usr/include/g-wrap
-O3 -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Werror -c
-o gnc-engine.lo `test -f 'gnc-engine.c' || echo './'`gnc-engine.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/libc -I../../src/core-utils
-I../../src -I../../src/gnc-module -I../../src/business/business-core/
-I../../src/engine -DGNUCASH -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I /usr/include/g-wrap -O3 -g -Wall -Wunused
-Wmissing-prototypes -Wmissing-declarations -Werror -c gnc-engine.c -MT
gnc-engine.lo -MD -MP -MF .deps/gnc-engine.TPlo -fPIC -DPIC -o
.libs/gnc-engine.o
In file included from gnc-engine.h:40,
from gnc-engine.c:28:
qof.h:99:23: qofla-dir.h: No such file or directory
gnc-engine.c:47:23: gncla-dir.h: No such file or directory
gnc-engine.c: In function `gnc_engine_init':
gnc-engine.c:100: error: `QOF_LIB_DIR' undeclared (first use in this function)
gnc-engine.c:100: error: (Each undeclared identifier is reported only once
gnc-engine.c:100: error: for each function it appears in.)
gnc-engine.c:102: error: `GNC_LIBDIR' undeclared (first use in this function)
make[3]: *** [gnc-engine.lo] Error 1
It seems, however, the qofla-dir.h does get built later in the process:
[EMAIL PROTECTED]:~/stuff/proj/gnucash/src-g2/gnucash/src/engine]$ ls -l
{qof,gnc}la-dir.h
ls: gncla-dir.h: No such file or directory
-rw-r--r-- 1 jsled users 1067 Oct 30 15:54 qofla-dir.h
If I force it built, then things are fine of course, but I shouldn't
need to.
...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: autogen.sh stops when trying cvs g2 build...
On Sun, Oct 30, 2005 at 02:48:32PM +0100, Michael Wahlbrink wrote: perhaps I've missed something important, but I don't know what ;-) If I try to build a g2 CVS version, then autogen.sh stops with the message, that there is no Makefile.in :-( Any hints?? Where is my error? I've done a cvs update -C before the autogen.sh run. Running automake --gnu ... lib/Makefile.am:4: required directory lib/glib26 does not exist lib/Makefile.am:2: required directory lib/glib26 does not exist src/import-export/Makefile.am:1: required directory src/import-export/schemas does not exist src/import-export/Makefile.am:2: required directory src/import-export/schemas does not exist configure.in:1425: required file `lib/glib26/Makefile.in' not found configure.in:1425: required file `src/import-export/schemas/Makefile.in' not found Sounds to me like a fresh CVS checkout might help. 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 Hope this helps a bit, -- Arnout Engelen [EMAIL PROTECTED] If it sounds good, it /is/ good. -- Duke Ellington ___ 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
Josh Sled wrote: On Tue, Oct 25, 2005 at 06:50:36PM -0400, Derek Atkins wrote: | Something like | http://www.goshaky.com/goshaky-distfiles/svn2rss/ | might be useful once SVN is in use - and rss feed of svn commits. | | RSS feeds are quite useful in their own ways Wouldn't be too hard to cook up a script that shows an RSS feed of the last n posts to gnucash-changes. In fact, I couldn't resist: http://bzzt.net/cgi-bin/gnucash-changes.cgi ;) Kind regards, Arnout ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Adding a Payroll calculator
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. ___ 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
build errors in src/backend/qsf/
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 qsf-backend.c: In function `write_qsf_from_book': qsf-backend.c:786: error: `QSF_SCHEMA_DIR' undeclared (first use in this function) qsf-backend.c:786: error: (Each undeclared identifier is reported only once qsf-backend.c:786: error: for each function it appears in.) qsf-backend.c: In function `write_qsf_to_stdout': qsf-backend.c:802: error: `QSF_SCHEMA_DIR' undeclared (first use in this function) qsf-backend.c: In function `load_qsf_object': qsf-backend.c:847: error: `QSF_SCHEMA_DIR' undeclared (first use in this function) make[4]: *** [qsf-backend.lo] Error 1 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. ...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: Conclusion about CVS to Subversion et al. discussion
On Sun, Oct 30, 2005 at 01:38:06PM +0100, Christian Stimming wrote: I think it's about time to conclude this version control discussion for now, make a decision based on the current consensus, postpone further discussion into next year, and continue coding on the gnome2 port for now. Agreed. From what we can see in the -devel and -patches discussion, everyone agrees that we should make a transition from CVS to a more modern version control system. Also, everyone would agree that SVN is in fact such a more modern version control system. Josh's test setup for the gnucash repository on SVN works already quite nice and gives a good impression of the benefits from SVN (like, svn diff for the full commit of one person at one time, or in other words: the full changeset can be viewed easily). There is no general agreement on whether a dedicated SCM like git would offer enough additional benefit so that a transition of the gnucash repository to such an SCM would be a good decision at this point in time. (For example, I tend to agree that there is enough additional benefit in such a move, but as I said, there is no general agreement.) s/dedicated/distributed/? I would therefore propose that we decide on the transition to Subversion *now*, and that this transition should happen in the next 1-2 weeks. If we're moving to svn, let's do it *soon*. I think Josh said in a couple weeks at the *beginning* of this thread. @David Hampton: Would you suggest to do the gnome2-branch merging to HEAD still in CVS, and make the transition to SVN after that? Or would you suggest that we can make the SVN-transition with the current repository, so that the gnome2-branch merging to HEAD will be done in SVN? If the former, then I would kindly ask whether the gnome2-HEAD merge could be done ASAP; if the latter, I would suggest that the transition to SVN should be done in the next 1-2 weeks. At the risk of delay, I would recommend do the merge before the move. Additionally, I would propose that we stop the discussion of the SCM issue now and reconsider this again at a later point in time (e.g., in six months from now), when we can already see whether some of the source control issues are already resolved by using SVN instead of CVS. Good proposal. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Mailing List Options [was Re: Switching...]
On Sun, Oct 30, 2005 at 02:15:37PM -0500, Josh Sled wrote: On Sun, 2005-10-30 at 20:01 +0100, Didier Vidal wrote: I've always wondered why the commits are systematically sent to gnucash-patches... This results in noise and an additional chance to forget or loose patches (since no dedicated tool exists to manage them). Why not just sending the patches, the patches acknowledgments and the patches commits to gnucash-patches ? I guess there's an argument for minimizing mailing-list management... but I could certainly see having 3 lists: - gnucash-patches (manual patch submission + ack + discuss) - gnucash-changes (commit notification, w/ diffs) - gnucash-commits (commit notification, w/o diffs) Or, optionally, only the first 2. My reflection on our development process has influenced my thinking about mailing lists, too. FWIW, here's my 50 cents: 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. In conclusion, -devel is for *development* and development involves patches so I think any setup that keeps source code off -devel is not good. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Conclusion about CVS to Subversion et al. discussion
On Sun, 2005-10-30 at 13:38 +0100, Christian Stimming wrote: @David Hampton: Would you suggest to do the gnome2-branch merging to HEAD still in CVS, and make the transition to SVN after that? In CVS. I would kindly ask whether the gnome2-HEAD merge could be done ASAP I was planning to do it this coming weekend, Nov 5th/6th. I'll see if I can get it done during the week. David ___ 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: 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. I generally agree that submitted patches could go to -devel without issue. (Assuming staying on a different list) We could have a standing rule that all discussion should immediately go to -devel... in the same way that -changes mails right now have a 'Reply-To: gnucash-devel[...]' header. 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. 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. ...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: Mailing List Options [was Re: Switching...]
G'day Josh, * Josh Sled [EMAIL PROTECTED] [051030 18:21]: 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. 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 suspect that a lot of us will just unsubscribe and then what little developer base there exists will really shrink. Few, if any testers are going to want to read the diffs. I know (currently) I don't. Cheers, S. pgpNKuV5JfsQC.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Conclusion about CVS to Subversion et al. discussion
On Sun, 2005-10-30 at 13:38 +0100, Christian Stimming wrote: I would therefore propose that we decide on the transition to Subversion *now*, and that this transition should happen in the next 1-2 weeks. +1. Additionally, I would propose that we stop the discussion of the SCM issue now and reconsider this again at a later point in time (e.g., in six months from now), when we can already see whether some of the source control issues are already resolved by using SVN instead of CVS. 0. I don't see my opinion on the matter changing substantially in the near term, but I don't see any reason not to entertain the idea again in the future. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing - Gnucash Preferences
On Sun, 2005-10-30 at 12:41 -0500, Volker Englisch wrote: David Hampton wrote: The default value for Register lines is set to 2. I think this value should be increased to display at least 3 lines in the Scheduled Transaction Editor. I see this as a default of 6 lines in the code. If you remove the ~/.gconf/apps/gnucash directory, restart gconf with 'gconftool-2 --shutdown', and then start gnucash do you still see a value of 2? I did this and found out that the default is actually set to '1' on my build. It must have already been updated since I build/updated my copy of GC last time. I'll create a new build soon and will then retest this the and the gconf druid as well. It's unclear after trying a few different vaules that it actually has the desired visual effect, right now. The value is being saved/loaded at the preferences/gconf/sx-dialog correctly, just not affecting the window layout/sizing. While I was looking at this I noticed something else. When you enter a split with the same Memo as the previous split the account is populated when tabbing to the account field. However, the account is not an existing account at all. It's just an account ID. I searched my data file for the account ID displayed but I couldn't find it. Sample: http://www.englisch.us/~volker/G2_Testing/SXAccount.jpg This has been a problem since 1.8, but I'd never really gotten it reproducible. This is nicely reproducible; thanks. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing - Scheduled Transactions/Register
On Thu, 2005-10-27 at 17:54 -0400, David Hampton wrote: I think my misunderstanding of the sx settings when I created the preferences may be contributing to the problem. Can you clarify for me whether my current understanding is correct. (Line numbers refer to the sxed dialog options settings in Tim's picture.) The create automatically seems to be a master setting. If clear, all the other settings are ignored. If checked, then transactions will be created on the date of the transaction. If the checkbox in line three is selected, then transactions will not be created on the actual date of the transaction, but will be created x days early. If transactions are being created automatically, the notify me when created checkbox seems obvious. You get a message when a transaction is created. I'm confused about the final line though. Does this move the creation announcement forward by x days, or is this an additional reminder that occurs in advance of creating the transaction. Also is this number of days calculated from the date of the transaction, or the date that the transaction will be created. For example, if I have a transaction to be created on December 1st, marked as create 7 days in advance and a reminder 10 days in advance, when does the reminder occur? November 14th (ten days before the transaction is created) or 21st (den days before the transaction is dated). As per coordination in #gnucash, I've already made these changes, but FTR I'll reply here... Create automatically conditionalizes only notify when (automatically) created -- if it's not being created automatically you'll be notified by definition in the SX-SLR dialog. The options code-named notify_days is really remind_days; I've renamed them in the schema and code appropriately to forestall future confusion with the other unrelated notify [when auto-created] option. The spinbuttons in this preference dialog behave *slightly* differently than in the editor; in the preferences, 0 is a magic value meaning don't check the create-/remind-in-advance option *and* make the value 0.; as a corollary: non-zero in the preferences means check the option and set the spinbutton to be this non-zero value. Thinking about it now, there's no real reason for the editor to have both a checkbox and a spinbutton: 0 can be a sentinel value there too... maybe I'll file an RFE for that later. I don't recall if the create-in-advance and remind-in-advance are cumulative, but they should be, of course. Otherwise, you can end up in a weird state. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: G2 Testing - Scheduled Transactions[/Register]
On Mon, 2005-10-24 at 02:23 -0400, Volker Englisch wrote:
I don't know if the scheduled transactions are ready for testing since
they crash GC frequently but here are a few things I noticed:
crash[ing] GC frequently is generally not my experience with them,
currently. If possible, can you attach to the crashed process with gdb
when you see the has crashed dialog and get a backtrace?
Do this by running gdb against '/usr/bin/guile', then attaching to the
PID mentioned in the crash dialog:
$ gdb /usr/bin/guile
gdb attach pid
gdb bt
When creating a transaction that is being created via the option Since
Last Run and listed in the To Create Transaction Preparation and I am
requested to enter a value (i.e. for a utility) clicking the Forward
button without entering the required value displays the To Create
Transaction Preparation window again. However, this time the size of
the read-only register at the bottom is increased (by a few pixels).
Pressing the Forward button repeatedly increases the register each time
by the same amount.
:( I was hoping we'd be past this perennial window-resize issue; I
notice in other threads your tree was a bit old; does this still occur
for you? I do not see this behavior; pressing forward simply selects
the next transaction that needs a variable binding and updates the
proposed-transaction register, without resizing.
The values for 'create NN days in advance' and 'Remind me NN days in
advance' can't be modified. These entered values can only be turned on
or off but the number of days can not be changed.
I've re-layed-out the dialog to deal with this. In gtk 1.x, any widgets
in the label of a checkbox were manipulable, but apparently not in gtk2;
I've made them two seperate widgets, side by side.
When I have the option for the 'Since Last Run' to 'Run when data file
opened' GC appears to be crashing frequently - when clicking in the
Scheduled Transactions window; when selecting preferences, when
scrolling, etc. So far, GC only crashed for me when I was working with SX.
Yeah, I notice a bunch of console noise when opening the SLR dialog. I
don't recall seeing the spewage here before, either. :( I've tried only
a few flows through the SLR dialog, and without crashes. I'll take a
deeper look. Any reproduction scripts you can offer would be great.
I also was able to crash GC when selecting the the option 'Draw
horizontal lines between cells' of the 'Register' preferences. (I
wanted to see if this option effects the SX window and it did in two
ways. :-) )
Selecting this option while the 'Since Last Run' window is open appears
to be a certain crasher but I still need to build a good test case.
I can reproduce this as well by:
- open SX editor
- close SX editor
- open Register prefs
- change either draw {horiz,vert} lines option
-- crash.
This leads me to believe SXes aren't cleaning up their register
properly...
On Tue, 2005-10-25 at 22:35 -0400, Volker Englisch wrote:
I did some more testing with SX:
- Creating a new SX
It appears that the values for the Days in Advance for a new SX are
being populated from the defaults listed in the preferences for
'Scheduled Transactions' even when the preferences are unchecked.
Set the values in the preferences to anything other then '0', then
uncheck the options.
Now create a new SX. The values from the preferences are being used
_and_ the options are checked by default.
These are fixed, now. The preferences are respected and populated.
- Creating a new SX
I'm setting the frequency of the transaction and the start date. After
this I want to specify the transaction and click anywhere in the
transaction template.
This causes the start date and the displayed calendar view to change
to 2004-01-01.
I cannot reproduce this; can you find a script to reproduce, please?
- Saving a new SX crashes GC. The message
unknown, but with movement
is displayed 50 times on the console.
(I had this come up twice but can't recreate it right now)
I am, however, able to save a new SX if I don't enter anything in the
transaction template.
I'm unable to reproduce this, either. The unknown, but with movement
messages relate to the selection-dragging code in the register, but I'm
not sure if they're related to the crash.
- Running the 'Since Last Run' I have a single transaction with status
Ready to create
The information for the split for this SX is not displayed in the
Transaction Template. When I click on the transaction to display
the split, GC crashes.
I cannot reproduce this; can you after the other register updates you took on?
However, if I click the forward button, the 'Transaction Review'
window appears and the program runs into a loop and the window size
increases. The bottom of the window moves towards the bottom of the
screen and the window needs to be canceled. The
Re: G2 Testing - Scheduled Transactions[/Register]
Josh Sled wrote: - Saving a new SX crashes GC. The message unknown, but with movement is displayed 50 times on the console. (I had this come up twice but can't recreate it right now) I am, however, able to save a new SX if I don't enter anything in the transaction template. I'm unable to reproduce this, either. The unknown, but with movement messages relate to the selection-dragging code in the register, but I'm not sure if they're related to the crash. Per your request the backtrace output: #0 0x0026b402 in __kernel_vsyscall () #1 0x0080df93 in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0x03738080 in libgnomeui_module_info_get () from /usr/lib/libgnomeui-2.so.0 #3 signal handler called #4 0x00a4b3ed in g_date_valid () from /usr/lib/libglib-2.0.so.0 #5 0x004396dd in gnc_sxed_update_cal () from /opt/gnucash2/lib/libgncgnome.so.0 #6 0x00439942 in gnc_sxed_freq_changed () from /opt/gnucash2/lib/libgncgnome.so.0 #7 0x00af87e7 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #8 0x00aed285 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #9 0x00afb75b in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #10 0x00afceb0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #11 0x02958330 in gtk_signal_emit_by_name () from /usr/lib/libgtk-x11-2.0.so.0 #12 0x00d675a9 in freq_option_value_changed () from /opt/gnucash2/lib/gnucash/libgncmod-gnome-utils.so.0 #13 0x00af87e7 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #14 0x00aed285 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #15 0x00afb75b in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #16 0x00afceb0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #17 0x00afd223 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #18 0x029221b1 in gtk_menu_shell_select_first () from /usr/lib/libgtk-x11-2.0.so.0 #19 0x00af87e7 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #20 0x00aecd9b in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #21 0x00aed285 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #22 0x00afb8e7 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #23 0x00afceb0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #24 0x00afd223 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #25 0x029222c7 in gtk_menu_shell_cancel () from /usr/lib/libgtk-x11-2.0.so.0 #26 0x0291d2cb in gtk_menu_get_for_attach_widget () from /usr/lib/libgtk-x11-2.0.so.0 #27 0x00af887b in g_cclosure_marshal_VOID__BOOLEAN () from /usr/lib/libgobject-2.0.so.0 #28 0x00aecd9b in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #29 0x00aed285 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #30 0x00afb3b0 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #31 0x00afceb0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #32 0x00afd223 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #33 0x029effe0 in gtk_widget_region_intersect () from /usr/lib/libgtk-x11-2.0.so.0 #34 0x029114d3 in gtk_false () from /usr/lib/libgtk-x11-2.0.so.0 #35 0x02854fab in gtk_bin_get_type () from /usr/lib/libgtk-x11-2.0.so.0 #36 0x028903ee in gtk_container_foreach () from /usr/lib/libgtk-x11-2.0.so.0 #37 0x029115ef in gtk_false () from /usr/lib/libgtk-x11-2.0.so.0 #38 0x029ffd77 in gtk_window_get_position () from /usr/lib/libgtk-x11-2.0.so.0 #39 0x00af87e7 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #40 0x00aecd9b in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #41 0x00aed285 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #42 0x00afb3b0 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #43 0x00afceb0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #44 0x00afd223 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #45 0x029ee66d in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0 #46 0x028a2839 in gtk_dialog_run () from /usr/lib/libgtk-x11-2.0.so.0 #47 0x00d6946f in gnc_verify_dialog () from /opt/gnucash2/lib/gnucash/libgncmod-gnome-utils.so.0 #48 0x00438eb4 in gnc_sxed_reg_check_close () from /opt/gnucash2/lib/libgncgnome.so.0 #49 0x00434c51 in sxed_close_handler () from /opt/gnucash2/lib/libgncgnome.so.0 #50 0x0024e8f7 in gnc_close_gui_component () from /opt/gnucash2/lib/gnucash/libgncmod-app-utils.so.0 #51 0x0024e975 in gnc_close_gui_component_by_data () from /opt/gnucash2/lib/gnucash/libgncmod-app-utils.so.0 #52 0x00434f84 in editor_ok_button_clicked () from /opt/gnucash2/lib/libgncgnome.so.0 #53 0x00af87e7 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #54 0x00aed285 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #55 0x00afb75b in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #56 0x00afceb0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #57 0x00afd223 in g_signal_emit () from
Re: GnuCash design / new features
Hi, I suggest you look at QSF and maybe help me finish off the conversion routines and invoice export. I will look at QSF, first. 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. 2. Someone else will undoubtedly have yet another target that should be considered. Probably. Maybe we could come up with something to enable customizing invoices without leaving the Gnucash GUI and iBiz applies one way. So, several suggestions could be incorporated to create something better than the wisdom of anyone person. 3. QSF *can* deal with ANY external customisation requests. By having just the data required, you can develop a simple Perl/Python/PHP/whatever process that parses the XML and produces the template / report / format you need for whatever your target may be. It's designed to be all things to all men and once a conversion script is created, it remains current because all that is changing is the internal data - not the QSF format itself. Sounds very high-level, generalized, and vague. I.e., I don't understand, but maybe I will after reading about QSF. Highly flexible, but using a GUI and a template creator. If it's flexible enough to import data into that template, QSF can provide the data. It's just a question of a suitable script to process the output. Who is expected to write the script? Who is Gnucash intended for? Are you happier in GUI development or CLI or both? Web dev and backend stuff is where I am most comfortable. Sounds perfect. Backend stuff will be the invoice QSF which still needs a few tweaks in src/business/business-core/gncInvoice.c and src/backend/qsf/qsf-backend.c - contact me off-list if you'd like to look into that and I can send you some examples. I will read about QSF. 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? 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
CVS, Oct 30, Build errors on x86_64
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? -- Karl Hegbloom [EMAIL PROTECTED] error.txt.gz Description: GNU Zip compressed data ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
