[GNC-dev] GnuCash Maint - general problem to enter year for 30.12. + 31.12. ?

[Carsten Rinke]

Hi,

today after building from the maint branch I noticed following behaviour:

Enter a new transaction with a date 31.12.2018 and press enter: 
31.12.2019 is displayed.


Try to edit and set it back to 2018 by "ctrl -" and press enter: 
31.12.2019 is displayed.


Try to set it to 30.12.2019 by using "-": 30.12.2020 is displayed.

Once that you change to 29.12. the year can be set normally again.


I went back and built again from the 3.4 release snapshot:

Here the issue is not reproducable.


Does anyone else see this, too?


Kind regards,
Carsten

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

Re: [GNC-dev] merging failing tests

[Carsten Rinke]

Thanks for all your comments.

@John, Geert:
Thanks for bringing the expectations to the point that unit tests as 
such and especially on master/maint always must pass.
I also get the point that further refinement of the test results by 
utilitzing the verdicts "xpass" and "xfail" is not desired. I have taken 
these out now (in #391, #404 to come).


Regarding: "disingenuous" - I needed to look it up.
Seems to be a very strong word of disappointment. My apologies for 
provoking this reaction. That was absolutely not my intention. Using 
#391 is just more appropriate as it already includes changes which I did 
not have a chance yet to put them to #404. That is why talking about 
#391 - that has the same problem as #404 - seemed more meaningful to me.


In General:
From the pure fact that code is not used it is very hard for me to 
judge if the code is not needed.
I can only see that a feature is already there, and conclude from this, 
that at some point it was agreed to be there. If it is not working, it 
should be fixed.
And of course I see the point that the effort to fix bugs that have not 
been complaint about should be balanced. In this special case the items 
can be fixed in reasonable short time.
By that is is okay for me, if these findings will never end up in 
master/maint. Getting to know the code and getting to know your 
expectations about proper testing (and getting some more historical 
lessons about GnuCash) is already a great gain.


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

[GNC-dev] merging failing tests

[Carsten Rinke]

Hi John,

I transfer this thread to this channel because I think this is not PR 
specific but more a general issue.


Let me start by saying that I do not want to "fight to get it merged". 
For me it is an interesting point to exchange views upon.


It is specifically about "We're not merging failing tests".

Example: PR#391
I have tried to follow your advice how to write SRFI-64 as good as I can 
at this point of time (I'm sure you will still find room for 
improvement, and that is fully ok).


In the test result from travis you can now see which tests are failing, 
and why, and I even mentioned the bug reports that I opened for it.


That the tests are not merged straight away is expected, no discussion 
about it, especially as long as the indicated bugs are not finally 
accepted as bugs.


But assume we agree that some bugs are really bugs, meaning, the test is 
correct, and it is correct that it is failing because the code is wrong:

Why not merging a failing test? Why waiting for the code fix?

Just to repeat: Please take these as open questions, I am not suggesting 
an answer here.


BTW:
I think I can propose fixes for most of the indicated bugs in PR#391, 
but I was planning to forward them as separate PRs. Good that you 
mention that I should place them into the existing PR.


/Carsten


Am 05.09.2018 um 01:29 schrieb John Ralls:


Since you haven't followed my instructions about how to write a 
SRFI-64 test it's impossible to tell from the output what is the 
problem... including knowing whether there's actually a bug in the 
gnc-html code or if it's in your tests. Yes, that's a defect in most 
of the Scheme test code, but fixing it was one of the main goals of 
adopting a proper unit test framework.


If your tests did find bugs then the PR needs to include fixes as 
separate commits. We're not merging failing tests and we're not 
merging non-tests. Consider that both of the failing tests in this PR 
seem not to matter: All of the existing report tests pass and the line 
charts work in use. If an important jqplot module isn't present or if 
the line chart plotting code was actually defective on Arch Linux that 
wouldn't be the case.


—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub 
, 
or mute the thread 
.




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

[GNC-dev] Report System Rework

[Carsten Rinke]

Hi,

this takes up a discussion with John and Christopher in PR#360 (and I am 
happy to see that is was merged :-D )


As the discussion turned away from the actual proposal of a test for the 
report definition, I'd suggest to move it to this channel.


John:
You were mentioning that you and Christopher are reworking the report 
system.
I had in mind to create even more PRs with test proposals for the report 
system (in response to Bug787401 which becomes a bit difficult now that 
the bug is closed ;-) ) and I wonder:

Is this idea still worth while?
Do you already have an idea about what is going to change?

Christopher:
Regarding your question below:
I think the report definition is triggered at the very beginning when 
the moduels are loaded.
inner_main triggers libgncmod_report_gnome_gnc_module_init 
(gncmod-report-gnome.c)
this triggers to load guile module "gnucash report standard-reports" 
(standard-report.scm)

this triggers to load all standard  reports
this triggers that (gnc:define-report) is called per report
-> it has nothing to do with html rendering

If you take the changes from PR#360 and comment out the report ID in the 
call to gnc:define-report from any standard report, you will see that an 
"ordinary" pop-up window is created.


-Carsten



 Weitergeleitete Nachricht 
Betreff:Re: [Gnucash/gnucash] Bug787401 test report definition (#360)
Datum:  Thu, 07 Jun 2018 03:47:52 -0700
Von:Christopher Lam 
Antwort an: 	Gnucash/gnucash 
 


An: Gnucash/gnucash 
Kopie (CC): 	GnuFiBux , Author 





I can understand the need to remove gui calls but not entirely sure 
exactly how the |(gnc:define-report)| is being called. I know they're 
being triggered with every report code e.g. at the end of 
transaction.scm, but not sure what exactly is causing the 
transaction.scm to be run. So, where will the gui error message be 
stated? As a html report perhaps?


—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub 
, or 
mute the thread 
.


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

Re: Building 2.8 on Ubuntu 16.04 - Wiki Proposal

[Carsten Rinke]

On 07.09.2017 12:38, Geert Janssens wrote:

On donderdag 7 september 2017 10:58:30 CEST Carsten Rinke wrote:

Hi there,

starting with an Ubuntu 16.04 installation from scratch, this is what I
did to make GnuCash 2.8 build with autotools:


Nice!


autogen.sh:
===
sudo apt-get install intltool
sudo apt-get install autoconf automake autotools-dev libsigsegv2 m4
sudo apt-get install libtool libltdl-dev
sudo apt-get install libglib2.0-dev

configure
=
sudo apt-get install icu-devtools libicu-dev
sudo apt-get install libboost-all-dev
sudo apt-get install guile-2.0 guile-2.0-dev
sudo apt-get install swig2.0
sudo apt-get install libxml++2.6-dev
sudo apt-get install libxslt1-dev
sudo apt-get install xsltproc
sudo apt-get install libgtest-dev
sudo apt-get install google-mock
sudo apt-get install gtk+3.0
sudo apt-get install libgtk-3-dev
sudo apt-get install webkit2gtk-3.0 # >600MB !


A few questions/remarks:

* Which packet pulls in the dev package for webkit2gtk ?

* I don't know whether this is also on Ubuntu, though on Fedora if you install
libgtk-3.dev, that will automatically pull in gtk+3.0 (using the Ubuntu
package names here)

* I'd condense this to one or two apt-get commands rather than the long list
of separate commands.

* Does listing this under separate build steps (autogen.sh vs configure) add
anything useful or could you just call it install system prerequisites or
something like that ?


make (xml backend)
=
mkdir build-master
cd build-master
../gnucash/autogen.sh

I didn't know you could call autogen.sh out of tree. If you can, so much the
better. It will however still create files in the source directory. So it may
be better to call this directly in the source directory to make this more
clear. I'm not sure about which way is best.


../gnucash/configure --prefix=/gnucash-master
--enable-compile-warnings --disable-error-on-warning --disable-dbi
make
sudo make install

If this looks ok to you I would put it onto the Wikipage 1:1 as a
starting point.

It's certainly a good starting point. I would definitely also illustrate how
to build with dbi enabled (many people want this) and which additional
dependencies this has.

And considering you wrote this for 2.8 I would consider using cmake instead of
autotools. It's very likely we will drop the latter as soon as we're sure our
cmake configuration does everything autotools does until now. The biggest
roadblock to this has recently been solved (running cmake on Ubuntu 14.04LTS)
so I was about to propose again to drop autotools.

Geert


For Webkit this is what I get from apt:

libwbclient0/xenial-security,now 2:4.3.11+dfsg-0ubuntu0.16.04.9 amd64 
[installed,upgradable to: 2:4.3.11+dfsg-0ubuntu0.16.04.10]

libwebkit1.1-cil/xenial,xenial,now 0.3-7 all [installed,automatic]
libwebkit2gtk-3.0-25/xenial-updates,now 2.4.11-0ubuntu0.1 amd64 [installed]
libwebkit2gtk-3.0-25-dbg/xenial-updates,now 2.4.11-0ubuntu0.1 amd64 
[installed]

libwebkit2gtk-3.0-dev/xenial-updates,now 2.4.11-0ubuntu0.1 amd64 [installed]
libwebkit2gtk-4.0-37/xenial-updates,xenial-security,now 
2.16.6-0ubuntu0.16.04.1 amd64 [installed]
libwebkit2gtk-4.0-37-gtk2/xenial-updates,xenial-security,now 
2.16.6-0ubuntu0.16.04.1 amd64 [installed]
libwebkitgtk-1.0-0/xenial-updates,now 2.4.11-0ubuntu0.1 amd64 
[installed,automatic]
libwebkitgtk-1.0-common/xenial-updates,xenial-updates,now 
2.4.11-0ubuntu0.1 all [installed,automatic]
libwebkitgtk-3.0-0/xenial-updates,now 2.4.11-0ubuntu0.1 amd64 
[installed,automatic]
libwebkitgtk-3.0-common/xenial-updates,xenial-updates,now 
2.4.11-0ubuntu0.1 all [installed,automatic]
libwebkitgtk-common-dev/xenial-updates,xenial-updates,now 
2.4.11-0ubuntu0.1 all [installed,automatic]

libwebkitgtk3.0-cil/xenial,now 2.0.0+git20151221-3 amd64 [installed]
libwebkitgtk3.0-cil-dev/xenial,now 2.0.0+git20151221-3 amd64 [installed]

APT shows following information for libgtk-3-dev:

apt show libgtk-3-dev
Package: libgtk-3-dev
Version: 3.18.9-1ubuntu3.3
Priority: optional
Section: libdevel
Source: gtk+3.0(<== ! Carsten: probably this is what 
you are looking for)

Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-disc...@lists.ubuntu.com>
Original-Maintainer: Debian GNOME Maintainers 
<pkg-gnome-maintain...@lists.alioth.debian.org>

Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 10,8 MB
Depends: libgtk-3-0 (= 3.18.9-1ubuntu3.3), gir1.2-gtk-3.0 (= 
3.18.9-1ubuntu3.3), libgtk-3-common, dconf-gsettings-backend | 
gsettings-backend, libglib2.0-dev (>= 2.43.4), libgdk-pixbuf2.0-dev (>= 
2.30.0), libpango1.0-dev (>= 1.37.3), libatk1.0-dev (>= 2.15.1), 
libatk-bridge2.0-dev, libcairo2-dev (>= 1.14.0), libepoxy-dev (>= 1.0), 
libx11-dev, libxext-dev, libxinerama-dev, libxi-dev, libxrandr-dev, 
libxcursor-dev, libxfixes-dev, libxcomposite-dev, libxdamage-dev, 
pkg-config, libegl1-mesa-dev, libwayland-dev (>= 1.5.91), 
libxkbcommon-dev, libmirclient-dev (>= 0.13

multi-column reports include incorrect sub-reports

[Carsten Rinke]

Hi Geert,

I am interested to have a look into *
* 

*Bug 764245*  
-multi-column reports include incorrect sub-reports


Just to save double-work:
Is this something that you are already close to resolve?

/Carsten

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

Building 2.8 on Ubuntu 16.04 - Wiki Proposal

[Carsten Rinke]

Hi there,

starting with an Ubuntu 16.04 installation from scratch, this is what I 
did to make GnuCash 2.8 build with autotools:


autogen.sh:
===
sudo apt-get install intltool
sudo apt-get install autoconf automake autotools-dev libsigsegv2 m4
sudo apt-get install libtool libltdl-dev
sudo apt-get install libglib2.0-dev

configure
=
sudo apt-get install icu-devtools libicu-dev
sudo apt-get install libboost-all-dev
sudo apt-get install guile-2.0 guile-2.0-dev
sudo apt-get install swig2.0
sudo apt-get install libxml++2.6-dev
sudo apt-get install libxslt1-dev
sudo apt-get install xsltproc
sudo apt-get install libgtest-dev
sudo apt-get install google-mock
sudo apt-get install gtk+3.0
sudo apt-get install libgtk-3-dev
sudo apt-get install webkit2gtk-3.0 # >600MB !

make (xml backend)
=
mkdir build-master
cd build-master
../gnucash/autogen.sh
../gnucash/configure --prefix=/gnucash-master 
--enable-compile-warnings --disable-error-on-warning --disable-dbi

make
sudo make install

If this looks ok to you I would put it onto the Wikipage 1:1 as a 
starting point.


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

Re: How to get gnc:gettext binding to work isolated for the report system?

[Carsten Rinke]

hi Derek,

sigh, you are right - I was working on the wrong report ID where the 
template name was #f.


Once you do it right it works like a charm.

Thanks for the eye opener.
/Carsten


On 12.03.2017 13:50, Derek Atkins wrote:

This error means the gnc:report-template-name function is returning #f.

-derek

Sent from my mobile. Please excuse any typos.

- Reply message -
From: "Carsten Rinke" <carsten.ri...@gmx.de>
To: "gnucash-devel" <gnucash-devel@gnucash.org>
Subject: How to get gnc:gettext binding to work isolated for the 
report system?

Date: Sun, Mar 12, 2017 7:54 AM

Hi,

I am trying to figure out how unit testing for the report system might
work, based on Glib-test.

The tests are run in the build/src/report/report-system/test
build-subdirectory, running make check.

Only the report system module is loaded by calling
gnc_module_load("gnucash/report/report-system", 0);

My understanding is that this automatically loads the modules for engine
and app-utils, too.

First tests for e.g. gnc:define-report are working now.

Now I get to procedures that include the call to gnc:gettext, which is
not working:
A call like
 (define rep-templ-name (gnc:gettext (gnc:report-template-name rep-templ)
ends up with
 ERROR: In procedure gnc-gettext-helper:
 ERROR: In procedure SWIG_Guile_scm2newstr: Wrong type argument in
position 1: #f

To me it seems that the SWIG binding towards gnc-gettext-helper (defined
in app-utils/gettext.scm) is not working with this test setup.

I tried to update report-system.i adding
  #include 
and
  char * gnc_gettext_helper(const char * str);
but after recompilation that does not show any effect, same error message.

Any idea how this binding could be resolved?

Thanks in advance,
Carsten

___
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

How to get gnc:gettext binding to work isolated for the report system?

[Carsten Rinke]

Hi,

I am trying to figure out how unit testing for the report system might 
work, based on Glib-test.


The tests are run in the build/src/report/report-system/test 
build-subdirectory, running make check.


Only the report system module is loaded by calling 
gnc_module_load("gnucash/report/report-system", 0);


My understanding is that this automatically loads the modules for engine 
and app-utils, too.


First tests for e.g. gnc:define-report are working now.

Now I get to procedures that include the call to gnc:gettext, which is 
not working:

A call like
   (define rep-templ-name (gnc:gettext (gnc:report-template-name rep-templ)
ends up with
   ERROR: In procedure gnc-gettext-helper:
   ERROR: In procedure SWIG_Guile_scm2newstr: Wrong type argument in 
position 1: #f


To me it seems that the SWIG binding towards gnc-gettext-helper (defined 
in app-utils/gettext.scm) is not working with this test setup.


I tried to update report-system.i adding
#include 
and
char * gnc_gettext_helper(const char * str);
but after recompilation that does not show any effect, same error message.

Any idea how this binding could be resolved?

Thanks in advance,
Carsten

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

Re: Building MAINT fails?

[Carsten Rinke]

Hi Frank,

thanks for the hint - that did the trick.

The change was introduced with
commit f54fc2ff11d4fe8a1b415081fb45f39fd73ba703
Author: Robert Fewell <14ubo...@gmail.com>
Date:   Mon Aug 1 12:45:35 2016 +0100
Commit: Geert Janssens <janssens-ge...@telenet.be> (Di 13 Sep 2016 
20:57:14 CEST)

Add option to recn cell type to be read only
Use added read only option to make Associate cell read only

After cleaning the installation dirs, it works fine again.

Interesting to see that the building process considers installed 
libraries ...


Kind regards,
Carsten


On 12.02.2017 17:14, Frank H. Ellenberger wrote:

Hi Carsten,

It seems to link against an old library (2.6.13), in which
`gnc_recn_cell_set_read_only' did not exist.
As I am no linker expert, I would suggest to search for outdated gnc
libraries, either from a previous build or provided by your distribution.

So first clean your install dirs. If that fails, uninstall your
distributions version.

HTH
Frank

Am 12.02.2017 um 15:45 schrieb Carsten Rinke:

Update:

I made a new clone from git hub -> no success, same error message

I checked out 2.6.14 -> no success, same error message

I checked out 2.6.13 -> success

What is so surprising about it: 2.6.14 once worked, I have a build done
on 20th Sep 2016 based on 2.6.14

Kind regards,
Carsten


On 11.02.2017 18:33, Carsten Rinke wrote:

Hi,

today I made git pull on the maint branch.

Last commit 260f1ba3124976c9ad620e197275135870772bed according to git
log.

After that I did the usual stuff:

mkdir build-maint
cd build-maint
../gnucash/autogen.sh
../gnucash/configure --prefix=/opt/gnucash-maint
--enable-compile-warnings --with-html-engine=webkit
--disable-error-on-warning --disable-dbi
make

It stops at this point:

Making all in bin
make[3]: Entering directory
`/home/cari/Developer/GnuCash/build-maint/src/bin'
Making all in .
make[4]: Entering directory
`/home/cari/Developer/GnuCash/build-maint/src/bin'
/bin/bash ../../libtool  --tag=CC   --mode=link gcc
-Wdeclaration-after-statement -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -g
-O2 -std=gnu99 -Wall -Wunused -Wmissing-prototypes
-Wmissing-declarations  -Wno-unused   -o gnucash gnucash-bin.o
../../src/register/ledger-core/libgncmod-ledger-core.la
../../src/report/report-gnome/libgncmod-report-gnome.la
../../src/gnome/libgnc-gnome.la
../../src/gnome-utils/libgncmod-gnome-utils.la
../../src/app-utils/libgncmod-app-utils.la
../../src/engine/libgncmod-engine.la
../../src/gnc-module/libgnc-module.la
../../src/core-utils/libgnc-core-utils.la
../../src/libqof/qof/libgnc-qof.la
../../src/report/report-system/libgncmod-report-system.la -lguile-2.0
-lgc   -pthread -Wl,--export-dynamic -lgio-2.0 -lgthread-2.0
-lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
-lcairo -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype
-lpthread  -lm
libtool: link: gcc -Wdeclaration-after-statement -Wno-pointer-sign
-D_FORTIFY_SOURCE=2 -g -O2 -std=gnu99 -Wall -Wunused
-Wmissing-prototypes -Wmissing-declarations -Wno-unused -o
.libs/gnucash gnucash-bin.o -pthread -Wl,--export-dynamic
../../src/register/ledger-core/.libs/libgncmod-ledger-core.so
../../src/report/report-gnome/.libs/libgncmod-report-gnome.so
../../src/gnome/.libs/libgnc-gnome.so
../../src/gnome-utils/.libs/libgncmod-gnome-utils.so
../../src/app-utils/.libs/libgncmod-app-utils.so
../../src/engine/.libs/libgncmod-engine.so
../../src/gnc-module/.libs/libgnc-module.so
../../src/core-utils/.libs/libgnc-core-utils.so
../../src/libqof/qof/.libs/libgnc-qof.so
../../src/report/report-system/.libs/libgncmod-report-system.so
-lguile-2.0 -lgc -lgthread-2.0 -lgmodule-2.0 -lgtk-x11-2.0
-lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0
-lgdk_pixbuf-2.0 /usr/lib/i386-linux-gnu/libcairo.so -lpango-1.0
-lfontconfig -lgobject-2.0 -lglib-2.0
/usr/lib/i386-linux-gnu/libfreetype.so -lpthread -lm -pthread
-Wl,-rpath -Wl,/opt/gnucash-maint/lib/gnucash -Wl,-rpath
-Wl,/opt/gnucash-maint/lib
../../src/register/ledger-core/.libs/libgncmod-ledger-core.so:
undefined reference to `gnc_recn_cell_set_read_only'
collect2: error: ld returned 1 exit status
make[4]: *** [gnucash] Error 1
make[4]: Leaving directory
`/home/cari/Developer/GnuCash/build-maint/src/bin'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/cari/Developer/GnuCash/build-maint/src/bin'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/cari/Developer/GnuCash/build-maint/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cari/Developer/GnuCash/build-maint'
make: *** [all] Error 2

What am I doing wrong?

Linux Ubuntu 14.04 LTS

Kind regards,
Carsten


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


___
gnucash-devel mailing list
gnuc

Re: Building MAINT fails?

[Carsten Rinke]

Update:

I made a new clone from git hub -> no success, same error message

I checked out 2.6.14 -> no success, same error message

I checked out 2.6.13 -> success

What is so surprising about it: 2.6.14 once worked, I have a build done 
on 20th Sep 2016 based on 2.6.14


Kind regards,
Carsten


On 11.02.2017 18:33, Carsten Rinke wrote:

Hi,

today I made git pull on the maint branch.

Last commit 260f1ba3124976c9ad620e197275135870772bed according to git 
log.


After that I did the usual stuff:

mkdir build-maint
cd build-maint
../gnucash/autogen.sh
../gnucash/configure --prefix=/opt/gnucash-maint 
--enable-compile-warnings --with-html-engine=webkit 
--disable-error-on-warning --disable-dbi

make

It stops at this point:

Making all in bin
make[3]: Entering directory 
`/home/cari/Developer/GnuCash/build-maint/src/bin'

Making all in .
make[4]: Entering directory 
`/home/cari/Developer/GnuCash/build-maint/src/bin'
/bin/bash ../../libtool  --tag=CC   --mode=link gcc 
-Wdeclaration-after-statement -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -g 
-O2 -std=gnu99 -Wall -Wunused -Wmissing-prototypes 
-Wmissing-declarations  -Wno-unused   -o gnucash gnucash-bin.o 
../../src/register/ledger-core/libgncmod-ledger-core.la 
../../src/report/report-gnome/libgncmod-report-gnome.la 
../../src/gnome/libgnc-gnome.la 
../../src/gnome-utils/libgncmod-gnome-utils.la 
../../src/app-utils/libgncmod-app-utils.la 
../../src/engine/libgncmod-engine.la 
../../src/gnc-module/libgnc-module.la 
../../src/core-utils/libgnc-core-utils.la 
../../src/libqof/qof/libgnc-qof.la 
../../src/report/report-system/libgncmod-report-system.la -lguile-2.0 
-lgc   -pthread -Wl,--export-dynamic -lgio-2.0 -lgthread-2.0 
-lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 
-lcairo -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype   
-lpthread  -lm
libtool: link: gcc -Wdeclaration-after-statement -Wno-pointer-sign 
-D_FORTIFY_SOURCE=2 -g -O2 -std=gnu99 -Wall -Wunused 
-Wmissing-prototypes -Wmissing-declarations -Wno-unused -o 
.libs/gnucash gnucash-bin.o -pthread -Wl,--export-dynamic 
../../src/register/ledger-core/.libs/libgncmod-ledger-core.so 
../../src/report/report-gnome/.libs/libgncmod-report-gnome.so 
../../src/gnome/.libs/libgnc-gnome.so 
../../src/gnome-utils/.libs/libgncmod-gnome-utils.so 
../../src/app-utils/.libs/libgncmod-app-utils.so 
../../src/engine/.libs/libgncmod-engine.so 
../../src/gnc-module/.libs/libgnc-module.so 
../../src/core-utils/.libs/libgnc-core-utils.so 
../../src/libqof/qof/.libs/libgnc-qof.so 
../../src/report/report-system/.libs/libgncmod-report-system.so 
-lguile-2.0 -lgc -lgthread-2.0 -lgmodule-2.0 -lgtk-x11-2.0 
-lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 
-lgdk_pixbuf-2.0 /usr/lib/i386-linux-gnu/libcairo.so -lpango-1.0 
-lfontconfig -lgobject-2.0 -lglib-2.0 
/usr/lib/i386-linux-gnu/libfreetype.so -lpthread -lm -pthread 
-Wl,-rpath -Wl,/opt/gnucash-maint/lib/gnucash -Wl,-rpath 
-Wl,/opt/gnucash-maint/lib
../../src/register/ledger-core/.libs/libgncmod-ledger-core.so: 
undefined reference to `gnc_recn_cell_set_read_only'

collect2: error: ld returned 1 exit status
make[4]: *** [gnucash] Error 1
make[4]: Leaving directory 
`/home/cari/Developer/GnuCash/build-maint/src/bin'

make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`/home/cari/Developer/GnuCash/build-maint/src/bin'

make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/cari/Developer/GnuCash/build-maint/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cari/Developer/GnuCash/build-maint'
make: *** [all] Error 2

What am I doing wrong?

Linux Ubuntu 14.04 LTS

Kind regards,
Carsten


___
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: Chart with option or separate reports

[Carsten Rinke]

Hi Wm,

yes, I refer to exactly this.

Quite some time ago (1 or 2 years?) I had setup quite a proper report 
structure with many (~10) reports added to a multi-column report, just 
to find out later that this solution is not reliable but displays wrong 
data at some point of time. I did not dig deeper into this at that time 
and simply stopped using the multi-column report.


I was happy to read that you were able to reproduce this so it really 
makes sense to dig into this.


Carsten

On 06.12.2016 19:45, Wm wrote:

On 06/12/2016 11:49, Carsten Rinke wrote:

Hi there,

just to let you know I am still alive :-)

Regarding: "Apparently these two were forgotten."
Actually, I noticed that there two ways of how reports had been
implemented, with e.g. Net Worth belonging to a more generic but also
more complex implementation than the others - do not remember the
details anymore.

My conclusion was, that a merge would be best, but it requires more
detailed understanding of the report system. I tried to get deeper into
this over the year, especially as I have an itch with the multi-column
report that is able to display the wrong reports, but failed to make
time for this due to my professional life :-(
Not sure, when I can continue ... but I keep this on my todo-list.

If you have time and ideas around this, you are more than welcome to
overtake :-)

Carsten, is the multi-column issue you mention the same as this ?
===
https://bugzilla.gnome.org/show_bug.cgi?id=764245
===
if so it is the first time I've noticed someone else experiencing it and
we might compare notes because I have never settled in my mind why it
sometimes happen and other times doesn't.

Meanwhile I have written some (external to gnc) scripts to accommodate
the fact that it does often go wrong so it is an irritation rather than
a disaster when it happens.



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

Re: Chart with option or separate reports

[Carsten Rinke]

Hi there,

just to let you know I am still alive :-)

Regarding: "Apparently these two were forgotten."
Actually, I noticed that there two ways of how reports had been 
implemented, with e.g. Net Worth belonging to a more generic but also 
more complex implementation than the others - do not remember the 
details anymore.


My conclusion was, that a merge would be best, but it requires more 
detailed understanding of the report system. I tried to get deeper into 
this over the year, especially as I have an itch with the multi-column 
report that is able to display the wrong reports, but failed to make 
time for this due to my professional life :-(

Not sure, when I can continue ... but I keep this on my todo-list.

If you have time and ideas around this, you are more than welcome to 
overtake :-)


Kind regards,
Carsten

On 02.12.2016 13:27, Geert Janssens wrote:

Op vrijdag 2 december 2016 10:21:54 CET schreef Robert Fewell:

Hi,

Just looking at making the chart reports more consistent

Good!


and noticed that
some have an option to select line or bar chart while 'Net Worth' and
'Income & Expenses' have separate reports.

Should these be changed to an option ?

Yes, that would be a good thing. This work was started by Carsten Rinke some
time ago. Apparently these two were forgotten.


If so, am I correct that each new combined report would require a new guid,
the old reports deleted and as the report version has been updated will not
cause concern.

That's only half of the story...
Imagine you are a user happily using gnucash 2.6 and you have several saved
report configurations based on one of the above mentioned reports. In addition
at least one report is still open in a tab.

Now you migrate to 2.8. What do you want to see happen as that user ? Well
nothing. Everything should just continue to work as before. That is of course
the ideal situation and not always achievable. But let's see how close we can
get...

You didn't specify what you intended to do with the old reports. I assume
you'd want to remove them as they have been superseded by your new reports.

That would mean the user loses both his saved reports and the open report
tabs.

So, to deal with this I  would
1. choose the post popular variant (which is either line or bar - a poll or
query on gnucash-user/gnucash-devel should give an idea) and amend that report
to also handle the other variant. So it would get the additional option,
defaulting to whichever was there originally. Don't change the report guid.
=> This would ensure that at least for the most popular variant the saved and
open reports just continue to work.

2. For the other variant, remove it from the reports menu, but internally keep
the report definition. Instead of a fully fledged report the code for this
other variant should just load the first variant with the additional, new
report option set. There are other examples of this in the reports code.
=> This would ensure the other saved and open reports continue to load. If
done properly they will be converted transparently in the new report format.

Finally, the version bump on saved-reports will prevent the new option from
ever appearing in the older saved-reports file for 2.6 and earlier.

The only thing we can't reasonably avoid is going back to gnucash 2.6 with a
new style report still open when leaving gnucash 2.8. In this case the most
popular variant from point 1 will appear in all situations, because the new
option isn't known in 2.6. Theoretically we could handle this as well by
defining the option in the non-gui parts of 2.6 already and redirect the
report if the option turns out to be set. IMO that would lead too far though.

Regards,

Geert
___
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: qof_instance_set/get_kvp cannot handle boolean?

[Carsten Rinke]

Hi John,

took a while, but now I checked: the "TaxRelated" flag of the accounts 
is working again as expected.


Thanks a lot,
Carsten


On 23.09.2016 18:30, John Ralls wrote:

On Sep 22, 2016, at 6:49 PM, Robert Fewell <14ubo...@gmail.com> wrote:

I noticed this before while doing my find account dialogue, at the start of 
pull request 83 there is a patch for this and the account hidden setting.

I've pushed a fix to master. Sorry, Bob, not yours, I decided to extract the guts 
to a new function and call it instead of copy

Regards,
John Ralls




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

qof_instance_set/get_kvp cannot handle boolean?

[Carsten Rinke]

Hi,

I try to make use of the "TaxRelated" flag of the accounts by calling 
xaccAccountSetTaxRelated (Account.c).


I notice that on master this does not lead to the same result as on maint.

To figure out what is wrong/different on master I simply added some 
printouts:


= snip start ===

gboolean
xaccAccountGetTaxRelated (const Account *acc)
{
GValue v = G_VALUE_INIT;
g_return_val_if_fail(GNC_IS_ACCOUNT(acc), FALSE);
qof_instance_get_kvp (QOF_INSTANCE(acc), "tax-related", );

if (G_VALUE_HOLDS_BOOLEAN ())
printf("G_VALUE_HOLDS_BOOLEAN returns TRUE\n");  <=
else
printf("G_VALUE_HOLDS_BOOLEAN returns FALSE, actually it is 
%s\n",G_VALUE_TYPE_NAME());  <=


if (g_value_get_boolean ())
printf("g_value_get_boolean returns TRUE\n");  <=
else
printf("g_value_get_boolean returns FALSE\n");  <=

return G_VALUE_HOLDS_BOOLEAN () ? g_value_get_boolean () : FALSE;
}

void
xaccAccountSetTaxRelated (Account *acc, gboolean tax_related)
{
if (tax_related)
printf("Request to set TaxRelated TRUE\n");  <=
else
printf("Request to set TaxRelated FALSE\n");  <=

GValue v = G_VALUE_INIT;
g_return_if_fail(GNC_IS_ACCOUNT(acc));

g_value_init (, G_TYPE_BOOLEAN);
g_value_set_boolean (, tax_related);

xaccAccountBeginEdit(acc);
qof_instance_set_kvp (QOF_INSTANCE (acc), "tax-related", );
mark_account (acc);
xaccAccountCommitEdit(acc);

if (xaccAccountGetTaxRelated(acc))
printf("TaxRelated is now TRUE\n");  <=
else
printf("TaxRelated is now FALSE\n");  <=
}

=== snip end =

The printout shows

Request to set TaxRelated TRUE
G_VALUE_HOLDS_BOOLEAN returns FALSE, actually it is gchararray
g_value_get_boolean returns FALSE
TaxRelated is now FALSE

My suspicion:

in kvp_frame.cpp in function

KvpValue*
kvp_value_from_gvalue (const GValue *gval)

= snip start ===
else if (type == G_TYPE_BOOLEAN)
{
auto bval = g_value_get_boolean(gval);
if (bval)
val = new KvpValue(g_strdup("true"));
=== snip end =

the information is lost that the origin is boolean. After this point I 
get lost.


What to do? Open a bug report?

Kind regards,
Carsten

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

Re: Reports: Utilization of urls

[Carsten Rinke]

Hi Geert,

"it is not a bug fix"
From end user point of view I disagree, but I agree that this is not an 
item to waste energy on.


"several of your patches I did review and commit only to revert them 
afterwards again"

I think that references the
- cashflow calculation issue, which the patch was later-on declared 
"obsolete - not a bug, but misunderstanding of function"
- the overlapping x-axis label issue, that showed problems on other 
distributions, which I could not see in my environment


"unit test set available for most of our guile modules"
Even though I very much support this idea: I don't think that this would 
have avoided the problems above, especially as it is not feasible for me 
to run a mutli-distro environment.
For me the question is, if there is man-power available to qualify and 
verify the solutions and patches before they are committed, best case: 
in different environments.

My perception is that currently this all falls back onto only your table.
Is my perception correct?

Independent of that:
What do you have in mind with a "unit test set"?
You mean documentation as kind of work instructions for testing?
Or do you mean an automated test framework?

Regards,
Carsten

On 13.03.2016 14:39, Geert Janssens wrote:


On Thursday 10 March 2016 18:58:56 Carsten Rinke wrote:

> I have the same point of view regarding the categorization:

> This is adding an optional representation mode to existing reports.

> Not making up new reports.

> This option is available already for the networth line chart (even

> though differently implemented), so I rather see this a bug fix

> instead of a new feature.

>

It's not a bug fix. The line chart views weren't there for these 
reports so you're not fixing something that didn't work properly. 
You're adding functionality that simply wasn't there yet. There's no 
use in trying to debate that.


Whether the new feature should be eligible for maint inclusion can be 
debatable. You'll find my motivation for not including it below.


> At the same time I see this a minor modification. So waiting 2 years

> to make this available for other users  that is a long way.

> But it has happened before that I have underestimated the complexity

> of the issue 

>

It's not so much you underestimating the complexity of the issue. I 
agree that the change itself in this case looks relatively small.


The complexity comes from the state of the guile code as a whole in 
gnucash. There is insufficient isolation in many cases. As a result 
making a trivial change for one issue can easily break another part of 
the code without any of us realizing.


That's why I tend to be extremely conservative in making changes in 
guile code in the stable series. I have underestimated these inter 
dependencies more than once in the past (among others with several of 
your patches I did review and commit only to revert them afterwards 
again due to complications). In each of the cases I believed the 
change was sufficiently local to be ok and was wrong. I don't feel 
like repeating that exercise on a regular basis.


If others want to review your patches and estimate whether they are 
safe to include in maint, I'm fine with that. I will stick to my 
conservative selection of only applying patches to maint I have 
sufficient confidence in they won't break the code in unexpected ways.


Note I would feel much more confident if we had a good unit test set 
available for most of our guile modules, which we don't. If you feel 
like it that's a very good area to contribute in as well :)


Regards,

Geert



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

Re: Reports: Utilization of urls

[Carsten Rinke]

Hi Frank,

I have to  admit, I am not sure if I get the point.

"who knows, what will be in 2 years"
certainly true, but if there is in option to add the fixes into master 
(more or less) now, why not adding it to maint, too?

What will be the difference in 2 years?
(note: I am refering to small changes, be it bugfixes or enhancements)

"that would be different if you asked for replacement"
These would mean to me big changes. These should only go to master, 
according to my understanding, unless something really weird shows up 
(e.g. jqplot turns out to be nothing more than a virus... - don't get me 
wrong, I like jqplot!)


"much room for improvements"
yepp



On 11.03.2016 15:40, Frank H. Ellenberger wrote:

Hallo Carsten,

Am 10.03.2016 um 18:58 schrieb Carsten Rinke:

I have the same point of view regarding the categorization:
This is adding an optional representation mode to existing reports. Not
making up new reports.
This option is available already for the networth line chart (even
though differently implemented), so I rather see this a bug fix instead
of a new feature.

At the same time I see this a minor modification. So waiting 2 years to
make this available for other users  that is a long way. But it
has happened before that I have underestimated the complexity of the
issue 

Regs,
Carsten

Perhaps another aspect:
I assume, you would now help us to fix issues in your modifications, but
who know, what will be in 2 years.

That would be different, if you asked for replacement of jqplot or
webkit by some much cooler stuff.

IMHO the reports are after the documentation the part of GC, where is
much room for improvements.

Regards
Frank



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

Re: Reports: Utilization of urls

[Carsten Rinke]

I have the same point of view regarding the categorization:
This is adding an optional representation mode to existing reports. Not 
making up new reports.
This option is available already for the networth line chart (even 
though differently implemented), so I rather see this a bug fix instead 
of a new feature.


At the same time I see this a minor modification. So waiting 2 years to 
make this available for other users  that is a long way. But it 
has happened before that I have underestimated the complexity of the 
issue 


Regs,
Carsten


On 09.03.2016 22:10, Geert Janssens wrote:

On Wednesday 09 March 2016 22:07:37 Geert Janssens wrote:

On Wednesday 09 March 2016 10:40:51 Derek Atkins wrote:

John Ralls <jra...@ceridwen.us> writes:

On Mar 8, 2016, at 11:32 AM, Carsten Rinke <carsten.ri...@gmx.de>
wrote:

The difference is the line chart option for budget reports: it
has
alrady been included on the master branch, but not on the maint
branch.
I did a git pull today again on both branches just to make sure I
did not miss anything.

Sorry, I didn't make the point clear: Should new reports be added
in
the middle of a stable release series or should they wait for the
next major release? If the latter then there should be no commits
to maint. The fact that line charts are already partly implemented
in master is a strong argument that the others should, too.

I feel that it's okay for new reports to get added in the middle of
a
stable release.

The patch is making changes in existing reports to extend their
behavior to either show a bar chart or a line chart. It's not adding
new, independent reports. I agree with John this should only be
committed to master in order to avoid unexpected issues in the stable
series.

Regards,

Geert

Note that I haven't had time yet to test the proposed patch or for a thorough 
code review.
That will follow later. The above conclusion is from a quick look at the patch.

Regards,

Geert
___
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: Reports: Utilization of urls

[Carsten Rinke]

The difference is the line chart option for budget reports: it has 
alrady been included on the master branch, but not on the maint branch.
I did a git pull today again on both branches just to make sure I did 
not miss anything.


Regards,
Carsten

On 07.03.2016 23:42, John Ralls wrote:

On Mar 7, 2016, at 10:15 AM, Carsten Rinke <carsten.ri...@gmx.de> wrote:

Ok.

I have submitted a patch for line charts in all reports (new Bug 763257, 
currently only for maint) and simply commented out those parts which were 
causing a warning message.
To be uncommented and re-worked, once urls get re-introduced.


I would be *really* surprised if a reports patch doesn't apply cleanly to both 
branches. What I'm not so sure about is whether we should save new reports for 
a new major release.

Regards,
John Ralls





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

Re: Reports: Utilization of urls

[Carsten Rinke]

Ok.

I have submitted a patch for line charts in all reports (new Bug 763257, 
currently only for maint) and simply commented out those parts which 
were causing a warning message.

To be uncommented and re-worked, once urls get re-introduced.

Regards,
Carsten

On 07.03.2016 17:29, Geert Janssens wrote:

On Monday 07 March 2016 11:08:50 Derek Atkins wrote:

Geert Janssens  writes:

GnuCash used to have interactive charts stem in the 1.x era. Back
then it used an guppi to plot
the charts.

Guppi was replaced with goffice during the migration to gtk2 (which
also started the 2.x series
of gnucash). I was not part of the team back then so I don't know
why
this choice was made. I
suspect guppi was never ported to gtk2.

Indeed, the issue was the Guppi was abandoned and wasn't ported to
Gtk2.  The closest tool at the time was Goffice, which is why that was
chosen.  Alas, Goffice didn't have support for active charts so we
lost the drill-down functionality.  There was much crying from the
userbase at the time, but when we suggested that someone would need
to take over Guppi it fell on deaf ears.   So here we are.


The goffice based chart rendering however is much more primitive. In
fact the only thing
gnucash did was to render the chart as a static image, which didn't
allow for any interaction at
all. The urls for interaction were kept in place as a reminder this
functionality got missing and
for someone to eventually figure out how to restore it.

This never happened until today.

Then jqplot was introduced between 2.4.x and 2.6. jqplot uses vector
graphics to plot the charts,
which is supported by many current webbrowsers. In theory vector
graphics do support
embedding of clickable links [1]. So with jqplot we're in a much
better position to potentially re-
enable links. It may not be supported by jqplot itself directly, but
there may be ways to add it
indirectly. (Note: I haven't investigated this at all...)


Should we take out all scheme-code that comes along with it?

Having said all that, I think we can just as well remove this code
unless someone is willing to do
the work to re-enable it. It just clutters the current code. If
someone wants to re-enable it in the
future, the current code is still in the git history to study and
revive then.

I would suggest we leave it for a bit longer; now that it's been
noticed, and knowing that jqplot might support it, I think removing it
only to add it in again in a few months if someone wants to work on
that feature seems to be a disservice.

I would propose, instead, that we should slate to remove it prior to
2.8 if it's not being used by then.


That's reasonable. Agreed.

Geert
___
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

Reports: Utilization of urls

[Carsten Rinke]

Hi,

when trying to introduce line charts to all graphical reports I run into 
the effect, that warnings are thrown in the area of setting up urls for 
the charts.


I think that is to make the charts interactive, so you can click on 
lines and bars or account names in the legend to open the corresponding 
account registers.


With the introduction of jqplot these kind of url utilization is not 
supported anymore (at least, I did not find support for it in the jqplot 
pages).


Should we take out all scheme-code that comes along with it?

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

Re: Still worth to look more deeply into Scheme?

[Carsten Rinke]

Hi John,

thanks for the quick reply.

"The problem with Scheme isn't so much that it's clumsy and 
old-fashioned, it's that not very many people know it and it takes a lot 
of work for people who are used to fortran/algol style languages to 
understand how to work with lisp-based ones."

-> I think, that is what I meant with clumsy and old-fashioned.

All in all, it I take this as: "There is still a long way to go until 
Scheme will become obsolete when it comes to the reports, so feel free 
to continue working with it."


Just to let you know: For me that is not a bad answer. Took a while, but 
nowadays I find Scheme programming no worse than programming in any 
other script language - there is always a hill to climb.


Regards,
Carsten

On 06.03.2016 16:20, John Ralls wrote:

On Mar 6, 2016, at 6:08 AM, Carsten Rinke <carsten.ri...@gmx.de> wrote:

Hi there,

after quite some time I started to recap on the activities that I had followed 
up.

Part of these were improvements on reports, mostly minor things like 
overlapping x-axis or introduction of line charts.

When coming to the line charts I came across the implementation of the networth 
charts.
My first impression is that these hint at a more modularized utilization of 
chart reports as this is implemented today.

I could think in the direction of working out a proposal for something more 
complex.

But is it still worth it?
Background to this question is that lately I read that scheme is considered 
clumsy and old-fashioned, so it should be take out of the project, replaced by 
something modern, maybe python.
If that is the case, I would stick to tiny improvements here and there that 
might make life a bit easier until the modernization has taken place.

What is the roadmap for replacing scheme with something else?
Will it be part of the C++ transition work, so it might be available around 
2018?

Carsten,

We're not really talking about the reports as part of removing Scheme. Rather 
there are parts of the main program that are done partly in Scheme and partly 
in C: Equation parsing and file properties (the business options, counters, 
trading accounts, etc.), and online quotes spring immediately to mind, but I 
think there are a couple of others. The QIF importer is implemented in Scheme 
but the others are in C. That's a serious obstacle to both portability and 
maintainability, so we want to clean it up and get it all in C.

What we eventually do with reports is an open question. The problem with Scheme 
isn't so much that it's clumsy and old-fashioned, it's that not very many 
people know it and it takes a lot of work for people who are used to 
fortran/algol style languages to understand how to work with lisp-based ones. 
I've suggested javascript in the past: It's a lot like scheme in terms of being 
more functional than procedural but with the more familiar curly braces and 
semicolons. Since we ship a browser as part of GnuCash it's also already 
available. I think our users would prefer something that doesn't require 
knowing programming at all, but designing something like that is not trivial. 
We talked about making GnuCash work with an external report writer, but there 
doesn't seem to be any suitable FLOSS package. Whatever we do with reports it 
would be at least two major releases out just because we need to get the lower 
level work done first.

I hope we'll have the lower-level work mostly done by 2018. When it is we'll be 
ready to discuss reporting more concretely.

Regards,
John Ralls




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

Still worth to look more deeply into Scheme?

[Carsten Rinke]

Hi there,

after quite some time I started to recap on the activities that I had 
followed up.


Part of these were improvements on reports, mostly minor things like 
overlapping x-axis or introduction of line charts.


When coming to the line charts I came across the implementation of the 
networth charts.
My first impression is that these hint at a more modularized utilization 
of chart reports as this is implemented today.


I could think in the direction of working out a proposal for something 
more complex.


But is it still worth it?
Background to this question is that lately I read that scheme is 
considered clumsy and old-fashioned, so it should be take out of the 
project, replaced by something modern, maybe python.
If that is the case, I would stick to tiny improvements here and there 
that might make life a bit easier until the modernization has taken place.


What is the roadmap for replacing scheme with something else?
Will it be part of the C++ transition work, so it might be available 
around 2018?


Kind regards,
Carsten
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: building master with boost

[Carsten Rinke]

Thanks for all feedback.

Finally I managed:
- I installed the library with the help from John and Aaron
- and I also used the = as indicated by Geert.

- Works all fine now :-)

Carsten

On 03.11.2014 16:50, Aaron Laws wrote:
On Sat, Nov 1, 2014 at 2:42 PM, Carsten Rinke carsten.ri...@gmx.de 
mailto:carsten.ri...@gmx.de wrote:


Hi,

to check if some front-porting is working, I tried to compile on
the master branch - for the first time.

It told me that boost is missing:

checking for boostlib = 1.48.0... configure: We could not detect
the boost libraries (version 1.48 or higher). If you have a staged
boost library (still not installed) please specify $BOOST_ROOT in
your environment and do not give a PATH to --with-boost option. 
If you are sure you have boost installed, then check your version

number looking in boost/version.hpp. See
http://randspringer.de/boost for more documentation.
configure: error: Boost 1.48.0 or later was not found and is
required to build GnuCash

So I downloaded Boost 1.56.0 into /opt/lib/boost/boost_1_56_0.

Running configure with an environment variable
echo $BOOST_ROOT - /opt/lib/boost/boost_1_56_0
does not change anything.

Running configure with
--with-boost /opt/lib/boost/boost_1_56_0
results in:
checking build system type... Invalid configuration
`/opt/lib/boost/boost_1_56_0': machine
`/opt/lib/boost/boost_1_56_0' not recognized
configure: error: /bin/bash ../config.sub
/opt/lib/boost/boost_1_56_0 failed

What can I do?

Kind regards,
Carsten
___
gnucash-devel mailing list
gnucash-devel@gnucash.org mailto:gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel



I do a similar thing, and here is what I pass to configure:

./configure --with-boost=/home/lmat/builds/development

(I trimmed out a dozen lines, but this should get to the gist of the 
matter.)


I built boost with

#!/bin/bash
cd boostsvn
./bootstrap.sh --prefix=/home/lmat/builds/development
./b2 install

I don't set BOOST_ROOT. Hopefully this helps?

In Christ,
Aaron Laws


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

building master with boost

[Carsten Rinke]

Hi,

to check if some front-porting is working, I tried to compile on the 
master branch - for the first time.


It told me that boost is missing:

checking for boostlib = 1.48.0... configure: We could not detect the 
boost libraries (version 1.48 or higher). If you have a staged boost 
library (still not installed) please specify $BOOST_ROOT in your 
environment and do not give a PATH to --with-boost option.  If you are 
sure you have boost installed, then check your version number looking in 
boost/version.hpp. See http://randspringer.de/boost for more 
documentation.
configure: error: Boost 1.48.0 or later was not found and is required to 
build GnuCash


So I downloaded Boost 1.56.0 into /opt/lib/boost/boost_1_56_0.

Running configure with an environment variable
echo $BOOST_ROOT - /opt/lib/boost/boost_1_56_0
does not change anything.

Running configure with
--with-boost /opt/lib/boost/boost_1_56_0
results in:
checking build system type... Invalid configuration 
`/opt/lib/boost/boost_1_56_0': machine `/opt/lib/boost/boost_1_56_0' not 
recognized

configure: error: /bin/bash ../config.sub /opt/lib/boost/boost_1_56_0 failed

What can I do?

Kind regards,
Carsten
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Design Docu - Archtitecture

[Carsten Rinke]

Hi John and Christian,

Thanks for the feedback. Happy to see that you read and even edit the page.

- Also, controllers are the code that interacts with the model to change data. 
It need not be GUI: E.g., importers are controllers.

Glad to hear this. I was guessing so, but did not dare ...

I have removed the engine part and if I get the message right this 
section should actually go back to the goals chapter as it hasn't really 
been followed up so far.
It also means that I would like to drop this topic because I would 
rather like to document what has been done until now instead of what 
should have been done.


- the current implementation is a mess with pieces of each component 
intermingled and spread throughout the code-base

Well, that might be the true, but I prefer not to put it like that in a 
what has been done until now docu :-)


Maybe we can go bottom up.

What data objects are there that would be part of the Model if the MVC 
had been adhered to?

Or is this all capsuled by QOF? Could we say QOF is the Model?

Kind regards,
Carsten

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

Re: Editing Wiki

[Carsten Rinke]

Geert, Derek,

Thanks, works great.
Just made myself familiar with a test upload (gnucash-icon.png, not 
meant to spam, feel free to delete).


Kind regards,
Carsten

On 21.09.2014 20:21, Geert Janssens wrote:

On Saturday 20 September 2014 12:47:27 Carsten Rinke wrote:

Hi,

who can put me on the list of authorized users to upload images to
Wiki?

/Carsten


Carsten,

I talked with Derek on irc just now and he has authorized your wiki
account to upload images.

Thanks for working on this!

Geert



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

Editing Wiki

[Carsten Rinke]

Hi,

who can put me on the list of authorized users to upload images to Wiki?

/Carsten

Hi,

Carsten Rinke carsten.rinke at gmx.de  
https://lists.gnucash.org/mailman/listinfo/gnucash-devel writes:


/  Hi,

//
//  two questions about the Wiki editing:
//
//  Currently I am not allowed to create new pages.
//  I read that there is a security mechanism that allows users to create
//  new pages only 1 week after registration.
//  I have registered more than a year ago, but I think my last login was
//  also more than a year ago.
/
Did you follow through with the email authorization?


/  - Does a login after a long while have the same effect as a new

//  registration with regard to the permission to create new pages?
/
Possibly; I'm not sure.


/  - How does an upload of images work? Is it supported for this wiki,

//  or should images not be used?
//  (I do not remember to ever have seen a picture somewhere in the wiki.)
/
It works but you must be manually added to the list of authorized users.


/  Kind regards,

//  Carsten
/
-derek


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

Wiki page for design documentation

[Carsten Rinke]

Hi,

following the advice I have created a Wiki page
http://wiki.gnucash.org/wiki/Project_and_Design_Documentation

Currently I feed it with what I found in doc/projects.html, so far I 
transferred the architectural design goals.


How should the review procecess look like?
Shall I notify you with every section that I think is ready (i.e. when 
I cannot update myself anymore without further help)?


Kind regards,
Carsten
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: design directory, ERM; was: Doxygen - is there a status?

[Carsten Rinke]

Hi,

sorry for the delay, but last weekend my computer broke down while I was 
on travel.

So I had to arrange for a replacement first.

Trying to avoid a detailed discussion, let me try to summarize what I 
understand up to here
- there is a difference of higher level design documentation and 
lower level design documentation, and the lower level part is 
currently in Doxygen/Git, the higher level part is available in bits 
and peaces in several places (Doxygen, texinfo files, Wiki, emails, etc.)
- a decision is needed whether to go for Wiki or Doxygen including the 
points
-- only Wiki for everything (meaning, move the lower level part to Wiki, 
too)

-- only Doxygen/Git for everything
-- Doxygen/Git for Lower level, Wiki for higher level

We have had quite different opinions so far about where and how the docu 
maintenance seems to be better. My impression is that no-one will 
convince no-one, no matter how long the discussion will be.


How do you usually take decisions?
Voting?

Kind regards,
Carsten

On 05.09.2014 00:11, John Ralls wrote:

On Sep 4, 2014, at 9:04 AM, Frank H. Ellenberger 
frank.h.ellenber...@gmail.com wrote:


Am 04.09.2014 um 16:26 schrieb John Ralls:

Just like Carsten you missed the point that the *design*
documentation doesn't and can't live in the code files and isn't part
of writing a patch.

Just for completeness:
There is a bunch of texi files in src/doc/design.
- But https://github.com/Gnucash/gnucash/commits/master/src/doc/design
shows only sparse updates after 2001.
- And Intro starts with This whole document is completely outdated.
Don't read this. All function names and every described structure has
changed completely. Only read this if you want to know how gnucash
looked like in 1999. This is completely outdated!

So, I agree, mediawiki texts are today easier to maintain than texinfo
files. Perhaps we should replace the content of this directory with a
file containing pointers to the respective wiki pages.

But we should add somewhere in the doxygen linked readme files
- A sketch of the modules, their purpose and relations

Better done in the master header file for each module than in separate “read 
me” files, but the problem is keeping them current.


- Explanation of namespaces gnc_, qof_, xacc_, …

Better idea: Let’s get rid of all of the extra namespaces and have just one.


BTW:
Am 03.09.2014 um 10:57 schrieb Carsten Rinke:

BTW: I took a look at the Wiki C API page. There is also good stuff
in it. Note that the link to the entity relationship diagram returns
404 and offers me a log in. Is that correct?

John, didn't you update the ERM some time ago? But later it became
inaccessible.

Yeah, I’d put it in the downloads section on Github. They dumped that service 
last spring and the diagram went away. I need to learn how to put images 
directly in the wiki.

Regards,
John Ralls




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

Re: Doxygen - is there a status?

[Carsten Rinke]

Ok.

Even though I think
- the tool (Doxygen, Wiki, plain files) is of no matter whether 
documentation maintenance works out or not

- it is not possible to work offline with Wiki in contrast to git/Doxygen

I consider this mail thread closed. Wiki as the tool of choice if it is 
not about API documentation.


Thanks so far for the hints.
I will come back with a first draft in Wiki, hopefully soon.

Carsten

On 04.09.2014 00:28, John Ralls wrote:

On Sep 3, 2014, at 8:07 AM, Carsten Rinke carsten.ri...@gmx.de wrote:


Hi,

what I (currently) have in mind is to use the Doxygen main page and related 
pages for pulling together all sort of conceptional design info I can find (by 
looking at the wiki, at html files from the tar ball, comments in the code, 
hints from this mailing list, whatever).
So this would make up files used and written only for documentation, no mix 
with code (like the currently available doxygen_mainpage.c file). Here I would 
also like to add some pictures.

The rest (Modules, Data Structures, Files, etc.) should come directly from the 
source files, basically as is.
Some source files contain quite a good implementation description.
Here the improvement that I currently see is to get the Modules in a more 
'obvious' order, but I have not that this through yet, so I might actually skip 
this.

Then I would think about whether the design descriptions could be brought into 
the source files tree, so they end up as more detailed descriptions in Doxygen. 
Again, not fully thought through. I am still in brainstorming mode to find a 
way that makes access to the design easier for those not having worked as a 
professional designers and programmers.

Something like this.

Basically this would remove the need to have a wiki as design documentation 
source.
The opposite strategy is to not put any design info at all into Doxygen and do 
it all in Wiki which I do not prefer if everything could done in one viewer.

That is the where you should stop me.

We’ve tried in-source design documentation, both in plain text files and in the 
module descriptions in the Doxygen-docs. It wasn’t maintained. We don’t need to 
repeat that experiment.

Let’s try moving it all to the wiki instead, and where appropriate link the API 
documentation. That has the added advantage that you can update the design docs 
directly without having to propose patches.

Both the Doxygen docs and the wiki are viewable in one viewer: The web browser. 
They can even link to each other when that’s appropriate.

Remember as well the discussions about our goals for the next two dev cycles. 
The design will change somewhat in support of those goals.

Regards,
John Ralls




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

Editing Wiki

[Carsten Rinke]

Hi,

two questions about the Wiki editing:

Currently I am not allowed to create new pages.
I read that there is a security mechanism that allows users to create 
new pages only 1 week after registration.
I have registered more than a year ago, but I think my last login was 
also more than a year ago.


- Does a login after a long while have the same effect as a new 
registration with regard to the permission to create new pages?


- How does an upload of images work? Is it supported for this wiki, or 
should images not be used?

(I do not remember to ever have seen a picture somewhere in the wiki.)

Kind regards,
Carsten


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

Re: Doxygen - is there a status?

[Carsten Rinke]

Oops, seems to be more left for discussion than I thought.

John,

you are absolutely right that design documentation should not reside in 
code files.
That is not what I was aiming at (even though sometimes a good 
implementation description can be half a design document - so there 
might be a gray area).


I guess I expressed myself a bit too short:

The way I understand Doxygen, you can create html files not only from 
the code files, but also from extra files that can live isolated from 
the code files, e.g. in the gnucash/doc directory (could also be the 
src/doc/design directory).
Doxygen can group information from those extra files in the mainpage 
and subpages, that are either linked from within (not being visible in 
the overview tree), or added to the tree in the related pages section.


I.e. the information from the extra files will show up in the main 
page and the related pages section.
The API documentation starts with the Module section and spans over the 
Data-Structures and Files sections.


My understanding is when using git as the common repository for code and 
design files
- it possible to have design documentation files for doxygen separated 
from the code files

- we can make use of the git benefits (including offline work)
- cross-referencing might be easier compared to using two repositories 
(git and wiki)
- the preferred editor can be used and the wiki online editor can be 
avoided (personally, I am not really a friend of it)


Hope that clears up my idea a bit (which might not be a new idea).
Carsten

On 04.09.2014 16:26, John Ralls wrote:
Frank, Just like Carsten you missed the point that the *design* 
documentation doesn't and can't live in the code files and isn't part 
of writing a patch. Other than that, your suggestions are indeed 
worthwhile: The API documentation in general could stand some 
improvement, and there are plenty of modules whose documentation is 
poor or nonexistant. Your point about access to the wiki when offline 
is valid, but the design docs are generally something that one reads 
as preparation rather than when writing code. The API docs are what 
most folks consult when coding. Still, it should be possible to create 
an offline version of a wiki section if one needs it. Regards, John Ralls 


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

Re: Doxygen - is there a status?

[Carsten Rinke]

Hi all,

thanks for the quick reply.

@Christian:

I have plenty.

Big ones like how does qof work? and small ones like what does xacc 
actually stand for?.
Geert's hint in one of the bugzilla replies to maybe consider listening 
to signals in an area that appears to me totally unrelated made me aware 
that I still do not know GnuCash at all.
By accident I found the project.html file which is also quite an eye 
opener, too.


BTW: I took a look at the Wiki C API page. There is also good stuff in it.
Note that the link to the entity relationship diagram returns 404 and 
offers me a log in. Is that correct?


My first proposal would be to try to get Doxygen into something more 
like book style - meaning leading the unaware reader to a starting point 
and offer a reading thread. No idea if that is possible, but I think it 
would help.


I also wonder in how far requirements can be documented with Doxygen.

But the first question is:
How am I going to do this formally?
Should I open an Enhancement Bug and feed it with patches as I go along?
Or should I iteratively attach whole tar archives with the Doxygen html 
result as I would propose it for review?


Regs,
Carsten

On 02.09.2014 19:46, Christian Stimming (mobil) wrote:
Hi Carsten, which questions do you want to get answered? If you have a 
few, I'd like to try to write up something.


Also, our wiki contains some text about the c API. Maybe this is of 
some help.


Regards, Christian

On 2. September 2014 17:10:00 MESZ, Carsten Rinke 
carsten.ri...@gmx.de wrote:


Hi,

Lately I was working on a bug (which I did not manage yet to fix).
During the investigations I noticed that I am still running around like
a blind chicken when starting out with a new bug.
And the reason is simple: Even though I have worked and programmed quite
a bit for GnuCash already, I still don't understand the architecture of it.

So I decided to try a top down approach instead of the buttom up in
order to learn a bit more about the 'big picture'.
And that is how I (once again) came across Doxygen.

While my first Doxygen attempts as a reader where ending up in confusion
and even more questions, I think I have now understood the idea. Still
my impression is that some high level and introducing paragraphs might
be helpful.
Currently it tells you more on how to make use of it as an author than
to actually use it as a reader.

I could start lookin!
  g into
ways how to improve it - but that implies
that stuff that I have in mind is really an improvement.

Therefore my first careful question:
What is the current status? Is there active work ongoing? Is it in
general agreed that additinional (even basic) work is needed in this
area? Or is everything (i.e. also conceptionally) in place as it should?

Kind regards,
Carsten


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


--
Sent from mobile. 


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

Re: Doxygen - is there a status?

[Carsten Rinke]

John,

actually I am in favor of Doxygen because then the design documentation 
and the implementation is put into one place, and it should be part of 
the designers work to maintain both, ideally in the same file. If using 
wiki, then you have to maintain two places. Not to forget the automated 
stuff that Doxygen is doing.


And as a side effect you get browsable code.

Is there / Has there been a discussion/decision about whether to use or 
not to use Doxygen?


Better stop me right away before I am running in the wrong direction ...

Regs,
Carsten


On 03.09.2014 16:00, John Ralls wrote:

On Sep 3, 2014, at 1:57 AM, Carsten Rinke carsten.ri...@gmx.de wrote:


Hi all,

thanks for the quick reply.

@Christian:

I have plenty.

Big ones like how does qof work? and small ones like what does xacc actually 
stand for?.
Geert's hint in one of the bugzilla replies to maybe consider listening to 
signals in an area that appears to me totally unrelated made me aware that I 
still do not know GnuCash at all.
By accident I found the project.html file which is also quite an eye opener, 
too.

BTW: I took a look at the Wiki C API page. There is also good stuff in it.
Note that the link to the entity relationship diagram returns 404 and offers me 
a log in. Is that correct?

My first proposal would be to try to get Doxygen into something more like book 
style - meaning leading the unaware reader to a starting point and offer a 
reading thread. No idea if that is possible, but I think it would help.

I also wonder in how far requirements can be documented with Doxygen.

But the first question is:
How am I going to do this formally?
Should I open an Enhancement Bug and feed it with patches as I go along?
Or should I iteratively attach whole tar archives with the Doxygen html result 
as I would propose it for review?

Carsten,

You can use Doxygen to build any arbitrary web site, though it's not 
necessarily the best way. I used it to build the project website for 
wxGuiTesting http://wxguitest.sourceforge.net/ several years ago.

Just attach patches. It's easy to apply them, build the Doxygen docs, and 
review the results.

But maybe it's better to get replace all of the (mostly outdated) design 
documentation in the code base with a set of wiki pages and leave Doxygen to 
document only the API. That's a much easier editing and collaborative flow than 
Doxygen patches and I suspect that it has a better chance of being maintained 
going forward.

Regards,
John Ralls




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

Re: Doxygen - is there a status?

[Carsten Rinke]

Hi,

what I (currently) have in mind is to use the Doxygen main page and 
related pages for pulling together all sort of conceptional design info 
I can find (by looking at the wiki, at html files from the tar ball, 
comments in the code, hints from this mailing list, whatever).
So this would make up files used and written only for documentation, no 
mix with code (like the currently available doxygen_mainpage.c file). 
Here I would also like to add some pictures.


The rest (Modules, Data Structures, Files, etc.) should come directly 
from the source files, basically as is.

Some source files contain quite a good implementation description.
Here the improvement that I currently see is to get the Modules in a 
more 'obvious' order, but I have not that this through yet, so I might 
actually skip this.


Then I would think about whether the design descriptions could be 
brought into the source files tree, so they end up as more detailed 
descriptions in Doxygen. Again, not fully thought through. I am still in 
brainstorming mode to find a way that makes access to the design easier 
for those not having worked as a professional designers and programmers.


Something like this.

Basically this would remove the need to have a wiki as design 
documentation source.
The opposite strategy is to not put any design info at all into Doxygen 
and do it all in Wiki which I do not prefer if everything could done in 
one viewer.


That is the where you should stop me.

Carsten


On 03.09.2014 16:37, John Ralls wrote:

On Sep 3, 2014, at 7:18 AM, Carsten Rinke carsten.ri...@gmx.de wrote:


John,

actually I am in favor of Doxygen because then the design documentation and the 
implementation is put into one place, and it should be part of the designers 
work to maintain both, ideally in the same file. If using wiki, then you have 
to maintain two places. Not to forget the automated stuff that Doxygen is doing.

And as a side effect you get browsable code.

Is there / Has there been a discussion/decision about whether to use or not to 
use Doxygen?

Better stop me right away before I am running in the wrong direction ...

Carsten,

The comments that go in the code files document API, ideally with an overview 
of that file’s contents, each class’s responsibilities, and then each 
function’s parameters and return value. Maintaining that is indeed part of 
maintaining the code.

Then there’s the overall design documentation. There’s no code file that 
applies to all of e.g src/engine or src/gnome-utils; QOF has qof.h, but over 
time src/libqof/qof has accumulated stuff that isn’t really part of QOF. We 
have instead src/doc, which hasn’t been touched in many years. Regardless of 
what we might like to enforce, I don’t foresee any real change in that 
behavior, and in any case the observation that one has to maintain two places 
holds true for code and src/doc.

The “automated stuff” that Doxygen does is convert jdoc markup in files it’s 
pointed at to HTML. The wiki does exactly the same stuff, just with different 
(and more familiar to most people) markup.

There hasn’t been a discussion about using Doxygen in *my* memory, but I’ve 
only been on the project for 5 years. That’s probably long enough that it’s 
worth revisiting now.

Regards,
John Ralls




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

Re: Bug 533738 - Budget report: Option Show full account names not supported

[Carsten Rinke]

Hi,

Dmitry is absolutely right: once you pick a single account from a lower 
level then the user has no chance to show the parent information in the 
report.


John's proposal sound reasonable to me.

Thanks for pointing that out.
I will update the bug with these comments.

Kind regards,
Carsten


On 08/11/2014 03:52 PM, John Ralls wrote:

On Aug 10, 2014, at 10:13 PM, Dmitry Pavlov zeldi...@gmail.com wrote:


User can select only specific accounts, not at the root of the account
tree, when building this report. With this use case full account name can
be helpful, so I'd suggest to fix that isssue instead of removing the
option from the code (or just hide it, but do not close the bug)


The root of the account tree is never visible and never named anywhere.

If, as Carsten says, the full hierarchy is always displayed with sub-accounts
indented, there's not much point to displaying the full account names for the
sub-accounts.

On the other hand, if Carsten is mistaken and one can select subaccounts and
have them displayed without their parents, ISTM the correct thing to do is to
always display the full account name of each highest-level account on the 
report.

Regards,
John Ralls




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

Bug 327636 - Budget GUI lacks help text - still a valid bug?

[Carsten Rinke]

Hi,

I have seen that *Bug 327636* 
https://bugzilla.gnome.org/show_bug.cgi?id=327636 -Budget GUI lacks 
help text


- is not assigned to gnucash-core-maint but to Chris Shoemaker
- has a very(!) short description

Is it still a valid bug?

Kind regards,
/Carsten
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Bug 533738 - Budget report: Option Show full account names not supported

[Carsten Rinke]

Hi,

because the bug is not yet assigned to gnucash-core-maint I post here my 
comments that I just added


budget.scm makes use of html-acct-table.scm to list the accounts.

After looking into html-acct-table.scm my guess is that displaying the full
account name is not intended because the accounts list is shown as a tree by
corresponding indent, so the parent accounts are easily identifiable.

From that point of view the fault reported by this bug is that the checkbox for
selecting full accounts name is available. The fact that the full account names
are not supported is ok.

And a fix would be to take out that option from the GUI.

Does that sound okay?

Kind regards,
Carsten
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Bug 612214 and Bug 726674 - duplicates?

[Carsten Rinke]

Hi Geert,

do you agree that
Bug 726674 https://bugzilla.gnome.org/show_bug.cgi?id=726674 - Budget 
Report always shows some inconsistent signs


is a duplicate of
*Bug 612214* https://bugzilla.gnome.org/show_bug.cgi?id=612214 
-Budgets are not aware of UI sign-reversals


?

Kind regards,
Carsten
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Budget View Implementation Question

[Carsten Rinke]

   Hi Phil, David and Christian,
   thanks for your replies.

   On 04/15/2014 10:51 PM, Phil Longstaff wrote:

Do you have top-level accounts which don't wouldn't fall under Income,
Expense, Assets, Liabilities or Equity?  Or, are you saying that if those
are your only top-level-accounts, they aren't included?  Or are you saying
that if they are in a different language (e.g. German), they aren't
included?

Phil

   I was using three top level accounts: Income, Asset, Expense
   Income has type income, Asset has type asset, Expense has type expense.
   All of them without children (goto Account Dialog, last item Parent
   Accounts has New Top Level Account selected).
   I use English locale.
   How do you get to the idea that this might be a language specific
   issue?

   On 04/16/2014 02:36 AM, David Carlson wrote:

 As a user I certainly agree that the budget feature should be
 substantially improved. I will ask what you mean by top level
 accounts, the five basic types (Asset, Liability, Income, Expense
 and Equity) or the first detail level just below those? I think that
 there are two or more types of usage for budgets, one being limited
 to income and expense, and another being more oriented to cash flow,
 which may include assets and liabilities, and the budget (and budget
 report) feature(s) should work for either. Are you actually
 discussing budget reports? I do not see the totals that you mention
 in the budgets that I have in my data file. I think that budget
 reports should be addressed separately to avoid confusion.
 Theoretically, there could be several budget reports linked to a
 given budget. They too need enhancement along with documentation.
 Whichever you mean, please be very specific. I would be willing to
 help with the documentation soon as I expect to have more time free
 if I can get a different (less resource hungry) antivirus program
 installed and operating.. The one I have now is killing me.

   Right now, I am only referring to the Bugdet editor
   (Actions-Budget), not any report from the Reports menu.
   I setup only one budget period, so next to the account tree I see two
   columns, one for the budget period, and one column for the totals. The
   totals column is fine for both the totals from the account tree and the
   total from the summary table at the bottom of the page. The budget is
   fine for the period column from the accounts tree, but shows only 0.00
   in the period column of the summary table at the bottom of the page.
   When adding children to the top level accounts, everything is working
   fine.
   I have read about the two budget usage types in the documentation
   (Income/Expense and Cash Flow), but I do no see a relevance of this
   section for the Budget editor. I read it more  as a recommendation, but
   as far as I can see the editor does not depend on any certain account
   setup (apart from the only one top level account per type).
   ... and good luck with the antivirus program ... ;-)

   On 04/16/2014 07:31 AM, Christian Stimming (mobil) wrote:

 I think those two limitations came in accidentally. When discussing
 and thinking about it, both should better be fixed instead of only
 being documented. If you have the time to do it, though.
 Regards, Christian

   For the Summary table only showing 0.00 for accounts without children
   issue I can provide a patch.
   For Only one top level account per type this is more complex, I
   believe that this is rather a concept related thing. In the very
   beginning, pointers are collected for each type, and only one pointer
   per type. And these are heavily in use afterwards. So my impression is
   that this is not trivial.
   What do you think about opening three bugs:
   - one for the Summary table only showing 0.00 for accounts without
   children (bug)
   - one for updating the documentation with the given limitation
   (enhancement)
   - one for removing the only one top level account per type supported
   issue (bug)
   The two first ones I see as candidates for 2.6.4++, while the last one
   I would not expect to start before 2.7.x (or whatever comes after 2.6).
   Kind regards,
   Carsten

   On 15. April 2014 19:32:15 MESZ, Carsten Rinke
   [1]carsten.ri...@gmx.de wrote:

Hi,

recently I started playing around with the budget feature, trying it out
with a simple account structure - only top level accounts.

Doing so I noticed
- In the summary view at the bottom of the page the totals per period
are not counted for top level accounts without children
- there is only one top level account per type allowed for the same
summary, no matter if they have children or not

I checked the documentation, but I did not see any hints to this
limitations.

Personally I would like to see the top level accounts considered, just
to avoid confusion.

The fact, to have only one top level account per account type is fine
with me

Budget View Implementation Question

[Carsten Rinke]

Hi,

recently I started playing around with the budget feature, trying it out 
with a simple account structure - only top level accounts.


Doing so I noticed
- In the summary view at the bottom of the page the totals per period 
are not counted for top level accounts without children
- there is only one top level account per type allowed for the same 
summary, no matter if they have children or not


I checked the documentation, but I did not see any hints to this 
limitations.


Personally I would like to see the top level accounts considered, just 
to avoid confusion.


The fact, to have only one top level account per account type is fine 
with me. Here I would be fine with an update of the documentation.


Bottom line: I propose two enhancement bugs, one for code, one for 
documentation.


Good proposal?

Kind regards,
Carsten
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: segfaults when running graphical reports

[Carsten Rinke]

Hi Klaus,

two first thoughts:

- is 'jqpplot' part of the package?
The display of graphical reports has changed from gnuplot to jqplot 
between 2.4 and 2.6.

Should reside under gnucash-installation-path/share/gnucash/jqplot.

- can you find something interesting in /tmp/gnucash.trace?
Maybe try running gnucash --debug --log gnc.scm=debug to get more info 
into this trace.


Gruss,
/Carsten


On 04/13/2014 09:35 AM, Thomas Klausner wrote:

Hi!

I'm using gnucash-2.6.3 from pkgsrc on NetBSD-6.99.40/amd64.

I see two recent changes compared to 2.4.13, the previous version in
pkgsrc.

The first: If I start gnucash without a terminal or in the background,
it doesn't finish startup. When started in the background, I see (with
zsh):


gnucash 

[1] 7303
[1]  + suspended (tty output)  gnucash

When I put it in the foreground again, it continues starting
successfully. This seems to happen during the splash screen, the last
thing that's displayed in the progress text at the bottom is
gnucash/python. Perhaps this is a problem with a python module, but
how do I find out which?

The worse problem I have is when I try to run a graphical report (e.g.
Income  Expense / Expense barchart) I get a segfault:

zsh: segmentation fault (core dumped)  gnucash

The backtrace is not very helpful, even when compiled with '-g -O0':
(gdb) bt
#0  0x7f7f87800a0c in ?? ()
#1  0x7f7f857fe088 in ?? ()
#2  0x7f7ff6a9efc0 in ?? ()
#3  0x7f7feb1641a8 in ?? ()
#4  0x7f7ff6a9e1c0 in ?? ()
#5  0x7f7fee3be8e8 in ?? ()
#6  0x7f7feecf9c00 in WTF::central_cache () from 
/usr/pkg/lib/libjavascriptcoregtk-1.0.so.0
#7  0x in ?? ()

I have webkit-gtk-1.10.2 installed if that matters.

Thanks,
  Thomas
___
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: segfaults when running graphical reports

[Carsten Rinke]

Hi Klaus,

the gnucash.trace file is created automatically and re-written at each 
start up.


Maybe you don't see it because your crash comes before this file is 
filled with data.


Just to double-check:
If you start gnucash successfully (no crash), and close it again 
gracefully (no attempt of graphical report creation) the file should be 
there.


Carsten

On 04/13/2014 10:10 AM, Thomas Klausner wrote:

Hi Carsten!

Thanks for your reply.

On Sun, Apr 13, 2014 at 09:56:11AM +0200, Carsten Rinke wrote:

two first thoughts:

- is 'jqpplot' part of the package?
The display of graphical reports has changed from gnuplot to jqplot between
2.4 and 2.6.
Should reside under gnucash-installation-path/share/gnucash/jqplot.

Yes:
/usr/pkg/share/gnucash/jqplot/jqplot.BezierCurveRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.barRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.blockRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.bubbleRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.canvasAxisLabelRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.canvasAxisTickRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.canvasTextRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.categoryAxisRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.ciParser.js
/usr/pkg/share/gnucash/jqplot/jqplot.cursor.js
/usr/pkg/share/gnucash/jqplot/jqplot.dateAxisRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.donutRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.dragable.js
/usr/pkg/share/gnucash/jqplot/jqplot.enhancedLegendRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.funnelRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.highlighter.js
/usr/pkg/share/gnucash/jqplot/jqplot.json2.js
/usr/pkg/share/gnucash/jqplot/jqplot.logAxisRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.mekkoAxisRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.mekkoRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.meterGaugeRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.ohlcRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.pieRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.pointLabels.js
/usr/pkg/share/gnucash/jqplot/jqplot.trendline.js
/usr/pkg/share/gnucash/jqplot/jquery.jqplot.css
/usr/pkg/share/gnucash/jqplot/jquery.jqplot.js
/usr/pkg/share/gnucash/jqplot/jquery.min.js
/usr/pkg/share/gnucash/scm/html-jqplot.scm

I see that these are javascript, does this need any particular support
in any of the libraries gnucash depends upon?


- can you find something interesting in /tmp/gnucash.trace?
Maybe try running gnucash --debug --log gnc.scm=debug to get more info
into this trace.

I don't have any /tmp/gnucash* , not even when I start it as you
suggested. How do I make gnucash create that?
  Thomas


Gruss,
/Carsten


On 04/13/2014 09:35 AM, Thomas Klausner wrote:

Hi!

I'm using gnucash-2.6.3 from pkgsrc on NetBSD-6.99.40/amd64.

I see two recent changes compared to 2.4.13, the previous version in
pkgsrc.

The first: If I start gnucash without a terminal or in the background,
it doesn't finish startup. When started in the background, I see (with
zsh):


gnucash 

[1] 7303
[1]  + suspended (tty output)  gnucash

When I put it in the foreground again, it continues starting
successfully. This seems to happen during the splash screen, the last
thing that's displayed in the progress text at the bottom is
gnucash/python. Perhaps this is a problem with a python module, but
how do I find out which?

The worse problem I have is when I try to run a graphical report (e.g.
Income  Expense / Expense barchart) I get a segfault:

zsh: segmentation fault (core dumped)  gnucash

The backtrace is not very helpful, even when compiled with '-g -O0':
(gdb) bt
#0  0x7f7f87800a0c in ?? ()
#1  0x7f7f857fe088 in ?? ()
#2  0x7f7ff6a9efc0 in ?? ()
#3  0x7f7feb1641a8 in ?? ()
#4  0x7f7ff6a9e1c0 in ?? ()
#5  0x7f7fee3be8e8 in ?? ()
#6  0x7f7feecf9c00 in WTF::central_cache () from 
/usr/pkg/lib/libjavascriptcoregtk-1.0.so.0
#7  0x in ?? ()

I have webkit-gtk-1.10.2 installed if that matters.

Thanks,
  Thomas
___
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



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

Re: segfaults when running graphical reports

[Carsten Rinke]

Hi Klaus,

I know this is a bit of playing around ...

Did you try running gnucash with the --debug --log gnc=debug option?
Does that reveal more info in the trace log?

Carsten

On 04/13/2014 10:45 AM, Thomas Klausner wrote:

Hi Carsten!

On Sun, Apr 13, 2014 at 10:34:20AM +0200, Carsten Rinke wrote:

the gnucash.trace file is created automatically and re-written at each start
up.

Maybe you don't see it because your crash comes before this file is filled
with data.

Just to double-check:
If you start gnucash successfully (no crash), and close it again gracefully
(no attempt of graphical report creation) the file should be there.

No, I don't get any gnucash* file in /tmp (or . or $HOME) even in with
a successful exit.

Ok, I've ktraced the process, the file is in /var/tmp/gnucash.trace.
Looking at it, I see a report:

* 10:41:43 MESSG gnc.scm script language=javascript type=text/javascript 
src=file:///usr/pkg/share/gnucash/jqplot/jquery.min.js/script
script language=javascript type=text/javascript 
src=file:///usr/pkg/share/gnucash/jqplot/jquery.jqplot.js/script
script language=javascript type=text/javascript 
src=file:///usr/pkg/share/gnucash/jqplot/jqplot.barRenderer.js/script
script language=javascript type=text/javascript 
src=file:///usr/pkg/share/gnucash/jqplot/jqplot.categoryAxisRenderer.js/script
script language=javascript type=text/javascript 
src=file:///usr/pkg/share/gnucash/jqplot/jqplot.highlighter.js/script
script language=javascript type=text/javascript 
src=file:///usr/pkg/share/gnucash/jqplot/jqplot.canvasTextRenderer.js/script
script language=javascript type=text/javascript 
src=file:///usr/pkg/share/gnucash/jqplot/jqplot.canvasAxisTickRenderer.js/script
link rel=stylesheet type=text/css 
href=file:///usr/pkg/share/gnucash/jqplot/jquery.jqplot.css /
div id=chart-968125 style=width:400px;height:400px;/div
script id=source
$(function () {var data = [];var series = [];
var d0 = [];
...
   function formatTooltip(str, seriesIndex, pointIndex) {
   if (options.axes.xaxis.ticks[pointIndex] !== undefined)
   x = options.axes.xaxis.ticks[pointIndex];
   else
   x = pointIndex;
   y = data[seriesIndex][pointIndex][1].toFixed(2);
   return options.series[seriesIndex].label + ' ' + x + 'brb' + y + 
'/b';
   }
});
/script

Then a few lines of (with varying x/y):

* 10:41:43  INFO gnc.account [xaccAccountGetBalanceInCurrency]  baln=x/y

And then it ends.
  Thomas


Carsten

On 04/13/2014 10:10 AM, Thomas Klausner wrote:

Hi Carsten!

Thanks for your reply.

On Sun, Apr 13, 2014 at 09:56:11AM +0200, Carsten Rinke wrote:

two first thoughts:

- is 'jqpplot' part of the package?
The display of graphical reports has changed from gnuplot to jqplot between
2.4 and 2.6.
Should reside under gnucash-installation-path/share/gnucash/jqplot.

Yes:
/usr/pkg/share/gnucash/jqplot/jqplot.BezierCurveRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.barRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.blockRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.bubbleRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.canvasAxisLabelRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.canvasAxisTickRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.canvasTextRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.categoryAxisRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.ciParser.js
/usr/pkg/share/gnucash/jqplot/jqplot.cursor.js
/usr/pkg/share/gnucash/jqplot/jqplot.dateAxisRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.donutRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.dragable.js
/usr/pkg/share/gnucash/jqplot/jqplot.enhancedLegendRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.funnelRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.highlighter.js
/usr/pkg/share/gnucash/jqplot/jqplot.json2.js
/usr/pkg/share/gnucash/jqplot/jqplot.logAxisRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.mekkoAxisRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.mekkoRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.meterGaugeRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.ohlcRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.pieRenderer.js
/usr/pkg/share/gnucash/jqplot/jqplot.pointLabels.js
/usr/pkg/share/gnucash/jqplot/jqplot.trendline.js
/usr/pkg/share/gnucash/jqplot/jquery.jqplot.css
/usr/pkg/share/gnucash/jqplot/jquery.jqplot.js
/usr/pkg/share/gnucash/jqplot/jquery.min.js
/usr/pkg/share/gnucash/scm/html-jqplot.scm

I see that these are javascript, does this need any particular support
in any of the libraries gnucash depends upon?


- can you find something interesting in /tmp/gnucash.trace?
Maybe try running gnucash --debug --log gnc.scm=debug to get more info
into this trace.

I don't have any /tmp/gnucash* , not even when I start it as you
suggested. How do I make gnucash create that?
  Thomas


Gruss,
/Carsten


On 04/13/2014 09:35 AM, Thomas Klausner wrote:

Hi!

I'm using gnucash-2.6.3 from pkgsrc on NetBSD-6.99.40/amd64.

I see two recent changes compared to 2.4.13, the previous version in
pkgsrc.

The first

Aw: Re: segfaults when running graphical reports

[Carsten Rinke]

   (oh dear, lucky those who can read ... sorry for that!)

   Hi Thomas,

   No, nothing obvious.
   I think that goes beyond my horizon - this is code I haven't looked at.
   Hopefully someone else can jump in.

   Just for curiousity:
   You see this everytime?
   You can reproduce this on a minimalistic book?

   Gruss,
   Carsten

   Gesendet: Sonntag, 13. April 2014 um 14:05 Uhr
   Von: Thomas Klausner t...@giga.or.at
   An: Carsten Rinke carsten.ri...@gmx.de
   Cc: GnuCash development list gnucash-devel@gnucash.org
   Betreff: Re: segfaults when running graphical reports
   Hi Carsten!
   I'm fine with trying out debugging options.
   With --debug --log gnc=debug, the log ends in:
   * 14:01:37 INFO gnc.account [xaccAccountGetBalanceInCurrency]
   baln=0/100
   * 14:01:37 DEBUG gnc.gui [leave gnc_tree_model_account_get_value()]
   * 14:01:37 DEBUG gnc.gui [enter
   gnc-tree-model-account.c:gnc_tree_model_account_get_iter()] model
   0x7f7ff1df4520, iter 0x7f7f9e48, path 0:3:9
   * 14:01:37 DEBUG gnc.gui [leave gnc_tree_model_account_get_iter()]
   iter [stamp:db6580d5 data:0x7f7ff2596e40 (nfotex), 0x7f7ff2596120, 9]
   * 14:01:37 DEBUG gnc.gui [enter
   gnc-tree-model-account.c:gnc_tree_model_account_get_value()] model
   0x7f7ff1df4520, iter [stamp:db6580d5 data:0x7f7ff2596e40 (nfotex),
   0x7f7ff2596120, 9], col 18
   * 14:01:37 INFO gnc.account [xaccAccountGetBalanceInCurrency]
   baln=0/100
   * 14:01:37 DEBUG gnc.gui [leave gnc_tree_model_account_get_value()]
   * 14:01:37 DEBUG gnc.html [enter
   gnc-html-webkit.c:impl_webkit_show_data()] datalen 7440, data !DOCTYPE
   html PUBLI
   * 14:01:37 DEBUG gnc.html [impl_webkit_show_data] Loading uri
   'file:var/tmp/gnc-report-XEN7DX.html'
   * 14:01:37 DEBUG gnc.html [enter
   gnc-html-webkit.c:webkit_navigation_requested_cb()] requesting
   file:var/tmp/gnc-report-XEN7DX.html
   * 14:01:37 DEBUG gnc.html [gnc_html_parse_url] parsing
   file:var/tmp/gnc-report-XEN7DX.html, base_location (null
   base_location)
   * 14:01:37 DEBUG gnc.html [leave webkit_navigation_requested_cb()]
   URI type is 'file'
   * 14:01:37 DEBUG gnc.html [leave impl_webkit_show_data()]
   * 14:01:37 DEBUG gnc.gui [enter
   gnc-plugin-page-report.c:gnc_plugin_page_report_load_cb()] load_cb:
   type=[report], location=[id=0], label=[(null)]
   * 14:01:37 DEBUG gnc.gui [gnc_plugin_page_report_load_cb] parsed id=0
   * 14:01:37 DEBUG gnc.gui [leave gnc_plugin_page_report_load_cb()]
   done
   * 14:01:37 DEBUG gnc.gui [leave
   gnc_plugin_page_report_create_widget()] container 0x7f7ff77fb320
   * 14:01:37 DEBUG gnc.app-utils.gsettings [enter
   gnc-gsettings.c:gnc_gsettings_get_schema_ptr()]
   * 14:01:37 DEBUG gnc.app-utils.gsettings
   [gnc_gsettings_get_schema_ptr] Looking for schema org.gnucash.general
   returned gsettings 0x7f7ff7b22920
   * 14:01:37 DEBUG gnc.app-utils.gsettings [leave
   gnc_gsettings_get_schema_ptr()]
   * 14:01:37 DEBUG gnc.app-utils.gsettings [enter
   gnc-gsettings.c:gnc_gsettings_get_schema_ptr()]
   * 14:01:37 DEBUG gnc.app-utils.gsettings
   [gnc_gsettings_get_schema_ptr] Looking for schema org.gnucash.general
   returned gsettings 0x7f7ff7b22920
   * 14:01:37 DEBUG gnc.app-utils.gsettings [leave
   gnc_gsettings_get_schema_ptr()]
   * 14:01:37 DEBUG gnc.gui [enter
   gnc-main-window.c:gnc_main_window_switch_page()] Notebook
   0x7f7ff731d0c0, page, 0x7f7ff77fb320, index 1, window 0x7f7ff7bcb240
   * 14:01:37 DEBUG gnc.gui [enter
   gnc-plugin.c:gnc_plugin_add_actions()] ui_merge 0x7f7ff77ea480,
   action_group 0x7f7ff67a5e60, filename gnc-plugin-page-report-ui.xml
   * 14:01:37 DEBUG gnc.gui [gnc_plugin_add_actions] merge_id is 21
   * 14:01:37 DEBUG gnc.gui [leave gnc_plugin_add_actions()]
   * 14:01:37 DEBUG gnc.gui [enter
   gnc-main-window.c:gnc_main_window_update_menu_item()] window
   0x7f7ff7bcb240
   * 14:01:37 DEBUG gnc.gui [enter
   gnc-main-window.c:gnc_main_window_update_one_menu_action()] window
   0x7f7ff7bcb240, action Window0Action, label _1 2014.gnucash (read-only)
   - Expense Over Time - GnuCash, visible 1
   * 14:01:37 DEBUG gnc.gui [leave
   gnc_main_window_update_one_menu_action()]
   * 14:01:37 DEBUG gnc.gui [leave gnc_main_window_update_menu_item()]
   * 14:01:37 DEBUG gnc.gui [leave gnc_main_window_switch_page()]
   * 14:01:37 DEBUG gnc.gui [leave gnc_main_window_open_page()]
   * 14:01:37 DEBUG gnc.gui [enter
   gnc-plugin-page-report.c:gnc_plugin_page_report_expose_event_cb()]
   report_draw
   * 14:01:37 DEBUG gnc.gui [leave
   gnc_plugin_page_report_expose_event_cb()] no reload needed
   Oh, that contains the filename
   file:var/tmp/gnc-report-XEN7DX.html -- opening that in firefox
   works.
   So I can at least look at the result :)
   I don't see anything obvious in the log though.
   Thomas
   (Btw, it's Thomas, not Klaus)
   On Sun, Apr 13, 2014 at 11:43:46AM +0200, Carsten Rinke wrote:
Hi Klaus,
   
I know this is a bit of playing around ...
   
Did you try running gnucash

Re: Creating Non-US Tax Reports

[Carsten Rinke]

Hi,

just to make you aware, I am working on something similar:
*Bug 710873* https://bugzilla.gnome.org/show_bug.cgi?id=710873 -New 
Tax Declaration Info Report - multi-national, multi-purpose (private, 
business, ...)


Right now it can be run in parallel to the TXF Code editor.
I am basically finished with what can be called feature 
implementation, and now turn to bug fixing - meaning: I am going to 
apply it for my own tax declaration this year.
If nothing serious comes up, I might have something to publish by mid of 
the year (incl. documentation).


Kind regards,
Carsten


On 01/29/2014 06:41 PM, Alex Aycinena wrote:

-- Forwarded message --
From: Clint Redwood cl...@screwtape.co.uk
To: gnucash-devel@gnucash.org gnucash-devel@gnucash.org
Cc:
Date: Wed, 29 Jan 2014 16:29:03 +
Subject: Creating Non-US Tax Reports
Hi!

Apologies if this has been done to death but googling found nothing
relevant.

Is there any way of setting up custom tax codes against accounts, and to
use the tax reports to do UK personal and corporation tax. It doesn't
appear to be able to be done inside the application but I wondered if there
is a configuration file I could modify to enable me to use this report
effectively, rather than just showing US forms and boxes. Clearly the
export isn't going to be relevant, but just having the report would be
useful.

Any suggestions or pointers welcome.

Thanks!

Yours,

Clint Redwood

Screwtape Limited, Registered 06663232, Babington House, 26 College Road,
Chilwell, Nottingham NG9 4AS


There is no easy way to use the existing US-based report for non-US income

tax reporting. Of course it can be done with a bunch of re-programming.

I maintain this part of gnucash and plan in the future to make changes that
actually would allow this. For the US, since the current system is based on
'txf' codes, the maintenance of which is dormant, the system is gradually
getting stale; I would like to make the 'txf' code not the key but an
attribute of a hidden key so that new codes could be added even if no
'txf'' code exists for an item. If I do this in a fairly generalized way,
then it could be used to support multiple taxing jurisdictions (within the
US and outside of the US) simultaneously. If in an even more generalized
way, it could support user-managed tagging of accounts, transactions, and
splits, a feature which has also been asked for and I would like to use
personally. But this will take a bit of effort and time to accomplish.

Alex
___
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: [Bug 710873] New Tax Declaration Info Report - multi-national, multi-purpose (private, business, ...)

[Carsten Rinke]

Hi Frank,

thanks for your comments. As I am not an accountant and also not 
familiar with business taxation there are a couple of questions to your 
comments - maybe even very basic ones.


First the most general question:
I am not sure if I should read a message like this is not a good idea 
from your comments, because it is colliding with other already ongoing work.
My general goal is to have a common framework for taxation that can be 
used for all (ok, let's say most) tax countries and tax types. The 
setup shall be adjustable per country.
My hope is that the work already done for Germany can be combined/merged 
with this. I volunteer to do the merging but I probably need some help 
for that (once I have reached that point).


My question: Do you agree or disagree that my approach can also be used 
for your purposes?


Other questions and comments I have inserted below.

Gruss,
Carsten


On 10/27/2013 01:49 AM, GnuCash (bugzilla.gnome.org) wrote:


--- Comment #4 from Frank H. Ellenberger frank.h.ellenber...@gmail.com 
2013-10-26 23:49:34 UTC ---
Created an attachment (id=258194)
  -- (https://bugzilla.gnome.org/attachment.cgi?id=258194)
Approach to get a german income tax declaration

Hi Carsten,

a few notes:

Comment #1:
  1. should become part of file property, to get it persistent. Then a user with
i.e. a business in DE and the home seat in BE could manage the sales tax (and
business income tax)in her DE file and the personal income tax in a BE file.
Hm, not sure. Currently the concept as shown in the attached prototype 
should allow for tax IDs for different countries in the same book. Might 
be useful, if you have international business, so I vote for not fixing 
it to the file properties.
The final scheme report has to check, if the report covers more than one 
country, and act accordingly.


  2. No:
   a) it is not in Preferences, but in Edit and it edits the tax properties of
the accounts in your current file.

Correct. Thanks for the hint and sorry for being unprecise here.

   b) It is also used for sales taxes like in SKR04, so INCOME tax would be
misleading.

This a comment that I do not understand.
I see sales tax as on of the tax types, so the can be covered with the 
given concept, so I do not really see what it is that is misleading here.
SKR04 seems to be a way of giving an identifier to certain business 
accounts. I tried to look it up in Wikipedia but that did not really 
take me far but I get the impression that this is specific for Germany 
and a few other countries.

Can you explain some more?


  3. TXF is form oriented, but
  a) The report is not.
As far as I found out TXF is a data format to transfer data between 
certain programs. It appears to me to be very specific and not related 
to the paper forms if you read TXF data. If it is form related, than 
the forms are needed for the given concept, TXF itself is not relevant 
for it (first step is only about data collection in a report, data 
transfer can be second stope afterwards).
By the way: The TXF related article in Wikipedia has been deleted 
(Article has no meaningful, substantive content).

  b) the german UStVA was originally a proof on concept which became useful for
german business users, but the de files need some rework to get it together
with the income tax declaration ESt.
  In 2008 I started an approach with the ESt2004 forms, but I got disrupted.
Probably we can take the attachement as a starting point for a german ESt
template.

Eventually you should search the german mailing list for some discussions a few
years ago leading to the german MWSt/VAT part in SKR04, electronic tax
reporting with ElStEr/libGeier...
There is also some background in http://wiki.gnucash.org/wiki/De/Projekte and
http://wiki.gnucash.org/wiki/De/SKR04

This part brought me to the general question at the top of this mail.




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

Re: [Bug 710873] New Tax Declaration Info Report - multi-national, multi-purpose (private, business, ...)

[Carsten Rinke]

Hi,

you might be right that I miss out completely some complexity.

First let me add that all that I am doing now will be done on top of 
what is existing, so anything that is already there remains untouched.


Secondly, I understand that the new tax info dialog can handle only 
certain level of complexity.


And now come the BUTs:
But I do not fully see how your comments related to the proposed 
solution (keep in mind that I do not run a business).
I get the point that the sales tax is applied in very many different 
ways within the US alone.


Is it that you try to hint me to the point that sales tax has not yet 
been implemented yet and that the new approach might not make it either? 
That might be correct, but that does not mean that a new approach might 
not be good enough for other tax types.


How are sales tax handled in GnuCash today? Doesn't it go to certain 
accounts from where you can get a sum over year?


How are sales tax declared? Isn't the principle of using paper based 
forms with certain fields somewhat similar to that of the other tax types?


Anyhow, I am focussing on the more simple types for now.

Kind regards,
Carsten

On 10/27/2013 08:16 PM, John Ralls wrote:

On Oct 27, 2013, at 11:13 AM, Mike or Penny Novack stepbystepf...@mtdata.com 
wrote:


Perhaps totally underestimating the scope of the problem.

For example, in the US there are 50 states, perhaps half of which have a sales 
tax. The problem isn't just that the rates would all be different but also that 
to what they apply (or not) would be different* and you'd need in addition a 
way to waive sales tax (for example, this customer is a non-profit that has 
filed a copy their exemption certificate with you). That's just for ONE country.

For doing this automated, leave to the folks (if any) trying to develop a point of 
sales system  (that would feed an accounting system like gnucash with the 
transaction already properly split).

Michael

* You might want an example of complexity? I am in Massachusetts. We have a 
sales tax but (in this state) it does not apply to items of clothing below a 
certain cost. If I bought a fancy coat for $300 it would be taxable. If I 
bought four dress pants at $80 per pair even though the total for those pair 
$320 that would not be taxable. If I went to a supermarket and bought various 
items of food (for home consumption), a bottle of laundry soap, and while there 
from the deli dept a sandwich to eat while in the store the food isn't taxed, 
the soap and the sandwich are.

  And proper calculation of sales tax amounts isn't to compute the tax 
individually on each item but to total up the taxables and compute the tax on 
that (like many states with sales tax the tax is rounded *up* to the nearest 
penny so if figured individually would average one cent more per item rather 
only rounding up once on the total). But I am far from certain all states work 
it that way.

California is similar in what's taxed, except that all clothing is. But to 
compensate in complexity, California has local-option sales taxes where cities 
and counties get to add on up to 1% each in 0.25% increments, so the tax is 
different from one city to the next.

Regards,
John Ralls




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

International Income Tax Info

[Carsten Rinke]

Hi,

as far as I can see the income tax info collection is only available for 
the US.
There is also some German business tax stuff implemented, but regarding 
income tax no international implementation is available yet.


If this is correct understanding then I would like to volunteer to 
implement such a international solution. This is not really trivial, 
so I would like to get some feedback if my idea outlined below has a 
chance to find a way into the main trunk before spending the hours on it.


Proposal for a solution:

1. Add a preference variable called Tax Country that lets the user 
choose the country for which he would like to declare tax. This should 
not be connected to the locale setting of the computer as for the German 
business tax implementation (I for myself always install my computers 
with english locale but I need to declare my taxes in Germany).


2. Currently the income tax info is collected in the dialog Preferences 
- Tax Report Options

Rename the dialog to Income Tax Editor and move it to the Tools menu.

3. Make the appearance of the dialog dependend on the preference setting 
for Tax Country.

This enables to display data for country specific tax declaration forms.

4. I am not familiar with the US tax system, but the the current dialog 
seems to be TXF focussed, and I wonder how much this is related to paper 
form based tax declarations. I would prefer a dialog that is structured 
more in analogy to the old school paper form declarations like
1. choose a form from a set of forms given for a certain type of tax 
declaration (here: income tax)

2. choose the line in this form to be filled in
3. choose the column to be filled in (if applicable, e.g. column for 
husband or wife)

4. choose the accounts that are relevant for the selected field

The concept that a scheme report has to be called to eventually display 
the resulting Income Tax Report remains untouched. If the preference 
says Tax Country US then the tax info dialog stays as is.


What do you think?

Kind regards,
/Carsten

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

Re: Multi-Column Report

[Carsten Rinke]

Hi Geert,

now I have created
*Bug 704525* https://bugzilla.gnome.org/show_bug.cgi?id=704525 -When 
you have a mix of chart types (bar charts and pie charts) then the pie 
charts do not work if the last chart is a bar chart


I even had a look into it and realized that these shoes are still a bit 
too big for me - so I will keep my hands off from this.

Thanks for picking it up.

Kind regards,
Carsten

On 07/14/2013 06:54 PM, Geert Janssens wrote:

Op 14/07/13 13:46, Carsten Rinke schreef:

Hi Geert,

have you had a chance to look at *Bug 638971* 
https://bugzilla.gnome.org/show_bug.cgi?id=638971 ? (Multicolumn 
report does not show more than one graph)


Just wanted to let you know that there still seem to be some issues 
about it and whether this should be followed up in the same bug or 
rather a new bug.


I could also start looking into this if you did not plan for this so 
far.

But I cannot commit to any delivery date (e.g. 2.5.4).

Can I join this topic or would that just be double-work?

Thanks and kind regards,
Carsten
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Hi Carsten,

Thank you for the heads up.

I saw your comment on the bug and have just replied to it.

I intend to look into this problem. But I won't be not at my 
development machine until the end of the month, so I can only look 
then. If you want to look into it before that time, you're welcome to 
do so. Otherwise I'll pick it up myself.


Geert
___
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

Multi-Column Report

[Carsten Rinke]

Hi Geert,

have you had a chance to look at *Bug 638971* 
https://bugzilla.gnome.org/show_bug.cgi?id=638971 ? (Multicolumn 
report does not show more than one graph)


Just wanted to let you know that there still seem to be some issues 
about it and whether this should be followed up in the same bug or 
rather a new bug.


I could also start looking into this if you did not plan for this so far.
But I cannot commit to any delivery date (e.g. 2.5.4).

Can I join this topic or would that just be double-work?

Thanks and kind regards,
Carsten
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Report system legacy

[Carsten Rinke]

Here comes a user's voice:
I also vote in favour of Derek's, Christian's and Herbert's preferences.

Carsten

On 06/29/2013 10:29 AM, Herbert Thoma wrote:

Am 28.06.2013 22:22, schrieb Christian Stimming:

I think we shouldn't add any suffix to the report name automatically. I also
think we shouldn't have multiple saved reports with the same name. To resolve
this, I think Derek's proposal works best: Saving the report requires a unique
name among the saved custom reports (but which might be identical to the non-
custom report). If the report with this name already exists as custom report,
the user gets a question Another report already exists with the name XX.
Overwrite? [Cancel] [Ok] and no additional options. If the user doesn't want
to overwrite, he/she always can guess to Cancel here and then change the
name to have it unique again.

I agree. We could add a third button [Choose different name] to open a
kind of save as dialog, if we want to get fancy.

  Herbert.
___
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: Help needed on the bug reports on gnucash reports?

[Carsten Rinke]

   Hi both,
   thanks for replying.
   Looks like there is no rule set. Ok, so I will go for whatever when I
   am back home.
   And I guess, that
   - for enhancements I will need to come back to this list in case of
   questions.
   - for bug assignments I will turn to Christian (so others have a chance
   to see that someone is working on the issue)
   Fair enough.
   Kind regards,
   Carsten

   On 05/09/2013 12:16 AM, David Carlson wrote:

On 5/8/2013 3:39 PM, Christian Stimming wrote:

Hi Carsten,

thanks a lot for all the work on the bugreports so far.

It is up to you which step to do next. Personally, I'd pick the enhancements
that align with your personal wishes, and do those...

Regards,

Christian



That method doesn't work for me.  After a while I would just quit.  I
would suggest choosing another criterion such as oldest first or
alphabetical.  That should mix things up between important to me and
important to others with a few trivial or nonsense items appearing from
time to time(those are probably from me).

David C


___
gnucash-devel mailing list
[1]gnucash-devel@gnucash.org
[2]https://lists.gnucash.org/mailman/listinfo/gnucash-devel

References

   1. mailto:gnucash-devel@gnucash.org
   2. 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: Help needed on the bug reports on gnucash reports?

[Carsten Rinke]

Hi Geert,

meanwhile I have started walk through the open bugs on the reports and 
hope to conclude it by next week (currently I cannot continue as I am on 
travel).


I start wondering what comes after:
- I could start trying to work on some of the bugs
- I could start working on the report documentation in order to have a 
baseline to judge if something really is a bug
- I could continue picking any enhancement that comes closest to my 
current personal wish and simply try to implement it

- etc.

Is there a rule set that helps avoid double work and let's me pick the 
right thing first?
Especially regarding enhancements: Who can decide if something is an 
enhancement or not before someone starts implementing it?


Thanks,
Carsten


On 03/26/2013 06:46 PM, Geert Janssens wrote:

[ Reposted from another mail address. Sorry if you received this mail twice ]

Hi Carsten,

Thank you for your offer to help us with the bug reports.

In addtition to your proposed suggestions, I would also like to add:
- if there's not enough information to reproduce a bug, ask the original
reporter for more details. Often a gnucash trace file helps already (1)
- in general make sure a bug report is complete: is the platform given
(linux/windows/mac, 32 bit/64bit, what happened, does it happen alway, how to
reproduce,...)
- find duplicate bugs and mark them as such
- ...

The other developers may has some additional suggestions.

Note that I have moved your question to the gnucash-devel mailing list since
it is development related.

Thanks again for volunteering.

Geert


(1) Where to find the gnucash trace file depends a bit on the user's platform.
Here is a link I usually provide to the bug submitters for more details:
http://wiki.gnucash.org/wiki/Tracefile


On Monday 25 March 2013 19:34:23 Carsten Rinke wrote:

Hi,

I just browsed through some of the bug reports about GnuCash reports.
Looks like some bugs have been confirmed but are still in status
unconfirmed since ages (and similar issues).

It seems, there is some cleanup needed, e.g. closing old and not
reproducable bugs, re-classifying reported bugs into enhancement
requests etc.

How can I help with that?
Carsten
___
gnucash-user mailing list
gnucash-u...@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


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

Re: Wish List

[Carsten Rinke]

Hi Shahram,

I'd suggest that you put your ideas into Bugzilla bug reports and mark 
them as enhancements.

(see also http://wiki.gnucash.org/wiki/Bugzilla)

BUT:
- Be very precise about what you suggest, and give as much context 
details as possible.
- file one bug per idea, do not put many ideas in to few bugs, this will 
be hard to track


To give you an idea what other readers might not fully understand 
(meaning right now: what I do not understand):


- allow multiple row selection in main window
- what is a main window? For me, the main window is the part where 
the accounts list, the reports, and the account registers are tabbed. So 
my guess is, you refer to the account registers, but, as said, this is 
only a guess.


- allow deletion without reconciliation
- deletion of what? Accounts? Transactions? Splits? Budgets? Scheduled 
transactions? ... you see what I mean?


- allow deletion of transaction
- this is already possible in the account registers. Does that delete 
button is not working for you?


- Transfer column
- again guessing that you now switched context to option selection in 
the report option selection dialog. Obviously, there are some options 
that you would like to be grouped. In case you file an enhancement bug, 
name at least some of the reports, if not all, that you want to have 
improved, and name exactly which options you are referring to and how 
you propose to have them grouped.


- automatically delete files from the GnuCash folder
- please describe, why the given possibilities (given in the 
preferences) are not sufficient from your point of view to achieve this 
goal


Having said this, I do not mean to discourage you. The more precise you 
are, the higher the chance the others understand your point, the higher 
the chance your wishes come true :-) )


Kind regards,
Carsten


On 04/28/2013 12:12 AM, Shahram wrote:

Hi

Just a few suggestions for GnuCash

Best wishes
Shahram



In main window and reconcile window
Allow multiple row selection
Allow multiple row deletion

In main window
Allow deletion without reconciliation

Allow deletion of transaction

Transfer column
For a faster choice of the options, allow hierarchical selection where
you could open and close main and sub categories

allow exports directly to spreadsheets

automatically delete extra files and logs from the Gnucash folder
___
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