Re: Stabilizing 2.4.0 (was Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.)

2010-03-05 Thread Donald Allen 
On Fri, Mar 5, 2010 at 7:04 PM, John Ralls  wrote:

>
> On Mar 5, 2010, at 2:59 PM, Phil Longstaff wrote:
>
> > Do we want to release a stable 2.4.0?  What do we need to finish to do
> > that.  There are lots of things happening in trunk, all of which will be
> > useful at some point, but many of which are destabilizing things.
>
> My feeling from the users list says they want the dbi backend and the new
> reporting made possible by WebKit, and that they'd like it soon. Maybe we
> should ask them what they want.
>

In addition to the new features, there are also bug fixes in the trunk
(e.g., the incorrect mortgage amortization calculation in scheduled loan
payments in 2.2.9; Derek sent a message to the users list saying  that he
thought that this problem had been fixed) that will be of value to the user
community.

/Don

>
> Regards,
> John Ralls
>
> ___
> 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: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.

2010-03-05 Thread Yawar Amin 
On 3/4/10 3:34 PM, Christian Stimming said:
> [...]
> Announcing a new sub-project in gnucash: The non-GUI parts are re-used in the 
> state they are, in the C language. This means the double-entry principles and 
> all of the other achievments in the "engine" and xml-backend and eventually 
> other backends can be re-used. But the GUI is rewritten completely new, from 
> scratch, in C++ and using the Qt toolkit. Fun again. The build system is 
> CMake 
> because its configuration runs magnitudes faster. Fun again. And as a final

Sounds fun. Are you doing this as a sub-project because you'd like to
see Cutecash become, someday, an optional (maybe default) front-end for
GnuCash? Or would you be OK with forking Cutecash off and
re-implementing a single Qt-based GUI? I ask because the latter option
seems more attractive to me--a separate, back-to-basics project can have
its own repo and forum, and can take advantage of the latest DVCS and
integrated web-hosted project sites (Launchpad, GitHub, BitBucket,
etc.). A Launchpad project may also be able to keep continuously
importing an SVN repo's commits and rebasing the project's own commits
on top of those. This last bit, I'm not sure of though. Even without it,
I think there's probably a way to keep tracking GnuCash development
while still working on a separate project.

Anyway, my point is that a simple, elegant and tightly-integrated
C++/Qt/WebKit financial app sounds like a very good idea, but it should
ideally be separate from the GnuCash project itself. Of course, you may
have a different end goal.

Cheers,

Yawar




signature.asc
Description: OpenPGP digital signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0 (was Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.)

2010-03-05 Thread John Ralls 

On Mar 5, 2010, at 2:59 PM, Phil Longstaff wrote:

> Do we want to release a stable 2.4.0?  What do we need to finish to do
> that.  There are lots of things happening in trunk, all of which will be
> useful at some point, but many of which are destabilizing things.

My feeling from the users list says they want the dbi backend and the new 
reporting made possible by WebKit, and that they'd like it soon. Maybe we 
should ask them what they want.

Regards,
John Ralls

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

Stabilizing 2.4.0 (was Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.)

2010-03-05 Thread Phil Longstaff 
On Fri, 2010-03-05 at 22:14 +0100, Christian Stimming wrote:
> Am Freitag, 5. März 2010 schrieb Phil Longstaff:
> > > To give this a try, have qt4 (>=4.5.0) and cmake (>= 2.6.0) installed
> > > and:
> > >
> > >   mkdir build-cutecash
> > >   cd build-cutecash
> > >   cmake ..
> > >   make
> > >   ./src/gnc/cutecash
> > 
> > It doesn't seem able to read any of my XML files.  Oh well.
> 
> Could you try again after r18841? This could very well be due to the business 
> data types missing yesterday, but I've added them today.
> 

Yes, that fixed it.

> > I would also like to suggest that work on this take a back seat to
> > getting 2.4 out the door.  Boring, yes, but there are lots of bugs in
> > bugzilla.  Can we go through and identify which ones we would like fixed
> > by 2.4?
> 
> Sure. However, I think the actual problem looks as follows: In order to 
> finish 
> a 2.4.0 release in finite time, we would finally have to look through those 
> features which are again and again buggy, then disable those, and call the 
> rest (which is relatively non-buggy) the next stable series. I think 
> everything else is prone to cause delay after delay again, without much fun 
> for the developers. However, decisions about which features better be 
> disabled 
> for a stable series are never easy to do. The infamous CSV importer comes to 
> mind... Nevertheless, I will agree with and support everyone who concentrates 
> on finishing a 2.4.0 release in near future. Thanks for reminding.

Do we want to release a stable 2.4.0?  What do we need to finish to do
that.  There are lots of things happening in trunk, all of which will be
useful at some point, but many of which are destabilizing things.  I am
not immune - by adding gobject properties to some of the engine objects
and converting the sql backend to use them, I broke some things.  Note
that one reason I am doing this is to make a more general CSV importer
which can handle importing any type of object much easier to implement.
Geert is doing good work factoring out URI routines, but by moving them
around, my win32 build isn't working.  My win32 build is using the mingw
gcc 4.4.0 compiler so that I can try a webkit 1.1.22 build (built with
4.4.3) that may fix the "can't load an logo into an invoice" problem.

If it were just me and my own personal use, I'd say all of the new stuff
is great.  I can build trunk whenever I want so can wait for the dust to
settle.  For my personal use, I like the cutecash effort.  One thing I'd
like to see is a dashboard idea (page of small graphs/tables which
highlight important info) which seems to fit into cutecash (and would
probably be easier to implement).

Since I was the one who originally made the push for 2.3.X/2.4.0, I feel
some responsibility to get 2.4.0 out the door.  I'm worried that we're
fragmented and making it harder on ourselves.

Do we just put out a new 2.3.X once a month and never come to a stable
version?  Works for me for my personal stuff, but what do other people
want?

Phil

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

Re: r18842 - gnucash/trunk - Use a normalized uri format internally to refer to data stores.

2010-03-05 Thread Phil Longstaff 
On Fri, 2010-03-05 at 15:15 -0500, Geert Janssens wrote:
> Author: gjanssens
> Date: 2010-03-05 15:15:31 -0500 (Fri, 05 Mar 2010)
> New Revision: 18842
> Trac: http://svn.gnucash.org/trac/changeset/18842
> 
> Added:
>gnucash/trunk/src/core-utils/gnc-uri-utils.c
>gnucash/trunk/src/core-utils/gnc-uri-utils.h
>gnucash/trunk/src/gnome-utils/gnc-keyring.c
>gnucash/trunk/src/gnome-utils/gnc-keyring.h
> Modified:
>gnucash/trunk/configure.in
>gnucash/trunk/po/POTFILES.in
>gnucash/trunk/src/backend/dbi/gnc-backend-dbi.c
>gnucash/trunk/src/backend/xml/gnc-backend-xml.c
>gnucash/trunk/src/core-utils/Makefile.am
>gnucash/trunk/src/core-utils/gnc-filepath-utils.c
>gnucash/trunk/src/core-utils/gnc-filepath-utils.h
>gnucash/trunk/src/gnome-utils/Makefile.am
>gnucash/trunk/src/gnome-utils/dialog-file-access.c
>gnucash/trunk/src/gnome-utils/druid-gnc-xml-import.c
>gnucash/trunk/src/gnome-utils/gnc-file.c
>gnucash/trunk/src/gnome-utils/gnc-main-window.c
>gnucash/trunk/src/gnome-utils/gnc-plugin-file-history.c
>gnucash/trunk/src/gnome/top-level.c
>gnucash/trunk/src/libqof/qof/qofsession.c
> Log:
> Use a normalized uri format internally to refer to data stores.
> 
> Data stores for GC can be a file (xml or sqlite3) or a database
> one some server (mysql or postgres).
> Wherever it makes sense internally, data stores will be referred to
> via a normalized uri:
> protocol://user:passw...@host:port/path
> Depending on the context and story type some of these parts are optional or 
> unused.
> 
> To achieve this, a new utility interface has been setup:
> gnc_uri__
> that can be used to manipulate the uris or convert from non-normalized
> formats to normalized and back.
> For example, when the user selects a file in the Open or Save As dialog,
> gnc_uri_get_normalized_uri will convert the file into a normalized uri.
> Or when the actual filename is needed this can be extracted with
> gnc_uri_get_path.
> You can also test if a uri defines a file or something else with
> gnc_uri_is_file_uri.
> 
> For the complete documentation, see src/core-utils/gnc-uri-uitls.h
> 
> This commit installs gnc-uri-utils and modifies the source where it makes
> sense to use its convenience functions. This concerns all functions that
> had to deal with file access in some way or another, the history module
> and the functions that generate the history menu list and the window titles.
> 
> Note that gnc-uri-utils replaces xaccResolveFilePath and xaccResolveUrl in 
> all cases.
> xaccResolveUrl has been removed, because gnc-uri-utils fully replaces its 
> functionality.
> xaccResolveFilePath is used internally in gnc-uri-utils to ensure an absolute 
> path
> is always returned (in case of a file uri, not for db uris). But it has been 
> renamed to
> gnc_resolve_file_path to be more consistent with the other functions.
> 
> Lastly, this commit also adds a first implementation to work with a keyring to
> store and retrieve passwords, althoug

gnc-keyring.c calls gnc_get_username_password() which is in
dialog-userpass.c so that now gnome-utils and gnome directories depend
on each other.

Phil

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

Re: Vision behind the Cutecash experiment (was: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.)

2010-03-05 Thread Bill Nottingham 
Christian Stimming (stimm...@tuhh.de) said: 
> I want to get in the place (again) where I can develop a finance software 
> with 
> a set of goals which are slightly different from those of the gnucash 
> project. 
> That's why I started Cutecash - just to see how far I and those who join can 
> get in reaching those goals. I have the following two goals in mind:
> 
>  #1: Create the best possible user experience in a finance management 
> software 
> 
>  #2: Have the highest possible amount of fun during development 

All I can say is that if rewriting an entire GUI interface from scratch in
C++ is what you find most fun, you're wired for a different sort of fun than
me. But more power to you.

> On the wiki page http://wiki.gnucash.org/wiki/Cutecash I've additionally 
> explained how some of my current design decisions are based on these two main 
> goals. If anyone prefers the decisions to be chosen differently, he/she is 
> very welcome to start a different project experiment, and we'll see the 
> outcome of each of us after some time. I've seen all sorts of design 
> decisions 
> in gnucash so far. With all this observations, now I came to the point where 
> I 
> told myself I have to make some of those decisions in a different way in 
> order 
> to have a fun project again. Cutecash is an experiment with such a different 
> set of design choices. It is up to the generous observer to decide which 
> result will look better in the long run.

My concern is... why is this then in the main GnuCash trunk? Why not just
have the configury in the main trunk to build the backend separate, and then
we can have as many UI forks as we have people want to do?

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

Vision behind the Cutecash experiment (was: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.)

2010-03-05 Thread Christian Stimming 
Dear all,

thanks for all the feedback about my announcement of the C++ Cutecash 
experiment. Actually, I'm not up to large technology discussions. My main 
motivation is something different, which I've explained in our wiki as well:

I want to get in the place (again) where I can develop a finance software with 
a set of goals which are slightly different from those of the gnucash project. 
That's why I started Cutecash - just to see how far I and those who join can 
get in reaching those goals. I have the following two goals in mind:

 #1: Create the best possible user experience in a finance management software 

 #2: Have the highest possible amount of fun during development 

Because of this, design decisions during development will have to be measured 
firstly by the user's point of view, and radically so. Which one out of many 
possible design options will give the best user experience? Which option will 
best fulfill the currently known user requirements? This option is what we 
will implement. No more, no less. In particular, we will radically ignore all 
requirements which are currently not yet known, or are not based on the user's 
point of view. 

If this first measure still leaves multiple options to choose from, we will 
generously choose the option which promises the most fun during development 
for us, the developers. 

If this second measure still leaves multiple options, we arbitrarily but 
boldly choose one option for now (like Wikipedia's "Be Bold") and move ahead. 
We might revise the decision later, but then, software has been rewritten many 
times already, so that's nothing uncommon or to be afraid of. We will just 
make the decision for now and move on. 

Some of these thoughts have been inspired by the book "Getting Real" by 
37signals. See http://gettingreal.37signals.com for a free on-line version.

On the wiki page http://wiki.gnucash.org/wiki/Cutecash I've additionally 
explained how some of my current design decisions are based on these two main 
goals. If anyone prefers the decisions to be chosen differently, he/she is 
very welcome to start a different project experiment, and we'll see the 
outcome of each of us after some time. I've seen all sorts of design decisions 
in gnucash so far. With all this observations, now I came to the point where I 
told myself I have to make some of those decisions in a different way in order 
to have a fun project again. Cutecash is an experiment with such a different 
set of design choices. It is up to the generous observer to decide which 
result will look better in the long run.

Best Regards,

Christian Stimming

Am Freitag, 5. März 2010 schrieb John Ralls:
> On Mar 4, 2010, at 12:34 PM, Christian Stimming wrote:
> >  Cutecash
> >  Free Finance Software. Easy to develop, easy to use.
> 
> Well, I'm a C++ booster, so I'm in favor. But for the long term, why keep
>  the core and engine in C? Letting the C++ genie out of the bottle means
>  that we can over time redesign and rewrite the non-gui code as well. (Have
>  you looked at Phil's roll-his-own vtable implementation in backend? He
>  could have done it in a tenth the code and probably a hundredth of the
>  time in C++. It would be faster, too, because the compiler would make
>  optimized vtables in machine code.)
> 
> While I would have preferred Wx to Qt, either is a big improvement over
>  Gtk+/Gnome for platform-independence, so another +1. Qt does have the
>  advantage that the aqbanking interface is already in Qt, so we need only
>  one toolkit. (Do note that there is a C++ interface to Gtk+ called Gtkmm.)
> 
> Regards,
> John Ralls
> 

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

Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.

2010-03-05 Thread Christian Stimming 
Am Freitag, 5. März 2010 schrieb Phil Longstaff:
> > To give this a try, have qt4 (>=4.5.0) and cmake (>= 2.6.0) installed
> > and:
> >
> >   mkdir build-cutecash
> >   cd build-cutecash
> >   cmake ..
> >   make
> >   ./src/gnc/cutecash
> 
> It doesn't seem able to read any of my XML files.  Oh well.

Could you try again after r18841? This could very well be due to the business 
data types missing yesterday, but I've added them today.

> I would also like to suggest that work on this take a back seat to
> getting 2.4 out the door.  Boring, yes, but there are lots of bugs in
> bugzilla.  Can we go through and identify which ones we would like fixed
> by 2.4?

Sure. However, I think the actual problem looks as follows: In order to finish 
a 2.4.0 release in finite time, we would finally have to look through those 
features which are again and again buggy, then disable those, and call the 
rest (which is relatively non-buggy) the next stable series. I think 
everything else is prone to cause delay after delay again, without much fun 
for the developers. However, decisions about which features better be disabled 
for a stable series are never easy to do. The infamous CSV importer comes to 
mind... Nevertheless, I will agree with and support everyone who concentrates 
on finishing a 2.4.0 release in near future. Thanks for reminding.

Regards,

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

Re: Required Cutecash dependencies (was: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.)

2010-03-05 Thread Christian Stimming 
Hi Herbert,

thanks for the feedback and your patch. I've commited your changes and some 
additions from me.

Am Freitag, 5. März 2010 schrieb Herbert Thoma:
> You require glib (and gobject, gmodule, gthread) 2.20.0 but GnuCash
> only requires 2.12.0.

Ok, I'll drop to what gnucash requires.

> You require Qt 4.5.0 but I have only 4.4.0.

Currently, the only 4.5.0-feature was the QSharedPointer, which I've removed 
again because it was unnecessary and not as powerful as I thought. However, I 
would like to stick to 4.5.0 as a requirement because it is already a year old 
and (more importantly) there isn't any easy way preventing to add 4.5-only 
features when developing with 4.5.x, which introduces unnecessary trouble. 

> The problem are some section like this:
> #ifndef HAVE_GUILE18
> --scm_block_gc;
> #endif
> in src/engine/engine-helpers.c
> 
> Do you know how to check for the guile version and how to set the
>  HAVE_GUILE18 if required in cmake?

I've added this as well. Thanks for pointing this out.

Also thanks for the suggestion with the extern "C" - I've changed this in all 
c++ files as well.

Regards,

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

Need some autotools and scm help

2010-03-05 Thread Geert Janssens 
Hi, I recently moved some files from src/engine to src/core-utils (gnc-
filepath-utils.*).

The move in itself went ok, but there are still some function definitions in 
src/engine/engine.i for functions that have moved to src/core-utils. I figured 
to simply move them from engine.i to src/core-utils/core-utils.i and be done 
with it (see the attached diff).

Unfortunately that doesn't work. Suddenly the report system complains about an 
unbound variable:
Backtrace:
In unknown file:
   ?: 0* [primitive-load-path "html-style-sheet.scm"]
In /home/janssege/Development/Sandbox/GC-Webkit/share/gnucash/scm/html-style-
sheet.scm:
 128: 1* (define gnc:current-saved-stylesheets #)
 129: 2* (gnc-build-dotgnucash-path "stylesheets-2.0")

/home/janssege/Development/Sandbox/GC-Webkit/share/gnucash/scm/html-style-
sheet.scm:129:3: In expression (gnc-build-dotgnucash-path "stylesheets-2.0"):   


/home/janssege/Development/Sandbox/GC-Webkit/share/gnucash/scm/html-style-
sheet.scm:129:3: Unbound variable: gnc-build-dotgnucash-path

I have been trying to solve this for half a day now, but I seem to get 
nowhere. I have tried adding
(use-modules (gnucash core-utils))
or
(gnc:module-load "gnucash/core-utils" 0)
to report-system.scm, but to no avail.

I must be missing something, but I don't know enough of how the guile 
integration works and the role automake plays in this.

Can someone a bit more experienced in this area give me some guidance or a 
pointer ?

Thanks,

Geert
Index: src/core-utils/core-utils.i
===
--- src/core-utils/core-utils.i	(revision 18831)
+++ src/core-utils/core-utils.i	(working copy)
@@ -2,6 +2,7 @@
 %{
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -34,4 +35,10 @@
   {
 return gnc_utf8_validate(str, -1, 0);
   }
+
+%newobject gnc_build_dotgnucash_path;
+gchar * gnc_build_dotgnucash_path (const gchar *filename);
+%newobject gnc_build_book_path;
+gchar * gnc_build_book_path (const gchar *filename);
+
 %}
Index: src/engine/engine.i
===
--- src/engine/engine.i	(revision 18831)
+++ src/engine/engine.i	(working copy)
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -69,8 +68,6 @@
 
 %newobject xaccSplitGetCorrAccountFullName;
 %newobject gnc_numeric_to_string;
-%newobject gnc_build_dotgnucash_path;
-%newobject gnc_build_book_path;
 
 /* Parse the header file to generate wrappers */
 %inline {
@@ -146,9 +143,6 @@
 
 Timespec timespecCanonicalDayTime(Timespec t);
 
-gchar * gnc_build_dotgnucash_path (const gchar *filename);
-gchar * gnc_build_book_path (const gchar *filename);
-
 %include 
 
 %typemap(in) GList * {
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.

2010-03-05 Thread John Ralls 

On Mar 5, 2010, at 7:05 AM, Donald Allen wrote:

> 
> I should have explicitly registered my agreement with Phil about focusing on
> getting 2.4 out. It's just over a year since 2.2.9 was released. While I
> don't think that's excessive given the nature of the project and the fact
> that the database back-end is a big deal,  I think with some focused effort
> on QA and bug-fixing, it can be ready for release in the near future. I
> think now is exactly the wrong time to get into an attention-diverting
> debate about languages and tools. That can and should wait, in my opinion,
> until 2.4 is released and known to be stable.
> 

While I disagree with Don about C++, I agree whole-heartedly about focussing on 
getting 2.4 shipped on schedule. We can have the language and toolkit 
discussions and decide whether to adopt Christian's branch afterwards.

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

Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.

2010-03-05 Thread Donald Allen 
On Fri, Mar 5, 2010 at 9:54 AM, Donald Allen  wrote:

>
>
> On Fri, Mar 5, 2010 at 8:42 AM, Phil Longstaff wrote:
>
>> On Thu, 2010-03-04 at 21:34 +0100, Christian Stimming wrote:
>> > I'd like to explain my recent experiments with C++ and cmake: I was
>> tired of
>> > the amount of code one has to write in the C language to achieve
>> seemingly
>> > trivial tasks. In my day-time projects with other, more GUI-suited,
>> > programming languages, the simple tasks can be written sooo much
>> simpler,
>> > leaving much more time for the actual challenging tasks. In gnucash,
>> over and
>> > over again I thought couldn't the GUI be written in any of the more
>> modern
>> > languages and/or toolkits. I mean, can we get the fun into gnucash
>> coding
>> > again?
>> >
>> > Actually, we can.
>> >
>> > Announcing a new sub-project in gnucash: The non-GUI parts are re-used
>> in the
>> > state they are, in the C language. This means the double-entry
>> principles and
>> > all of the other achievments in the "engine" and xml-backend and
>> eventually
>> > other backends can be re-used. But the GUI is rewritten completely new,
>> from
>> > scratch, in C++ and using the Qt toolkit. Fun again. The build system is
>> CMake
>> > because its configuration runs magnitudes faster. Fun again. And as a
>> final
>> > bonus, for MS windows more compiler than before are supported, namely
>> this
>> > whole new project can be compiled by MS Visual Studio as well. So here
>> it is:
>> >
>> >   Cutecash
>> >   Free Finance Software. Easy to develop, easy to use.
>> >
>>
>>
>> > Currently this is only a proof-of-concept for developers: You can load
>> an
>> > existing gnucash XML file, and it will show the list of accounts as a
>> flat
>> > table in a QTableView. The fun part is how easy it was to add this
>> display of
>> > all accounts, so it will probably take only another 1-2 hours until the
>> > account list is a tree to be viewed in a QTreeView. And a QTableView
>> with the
>> > splits of an account can't be far...
>> >
>> > To give this a try, have qt4 (>=4.5.0) and cmake (>= 2.6.0) installed
>> and:
>> >
>> >   mkdir build-cutecash
>> >   cd build-cutecash
>> >   cmake ..
>> >   make
>> >   ./src/gnc/cutecash
>> >
>> > Have fun (again)!
>>
>> It doesn't seem able to read any of my XML files.  Oh well.
>>
>> While this may be/is guaranteed to restart the various language wars
>> (can we do this in Visual Basic, please :)), I think it's a great idea -
>> use the best tools available for different parts of the code.
>>
>> Someone (John Ralls?) asked why we would keep the core in C.  Wx vs Qt
>> came up.
>>
>> I'd like to see discussion of why different technologies would be used
>> for various parts of the system.  What features does the engine need?
>> Why C++ for the UI?  Would we do better with a language using garbage
>> collection so that we don't need to worry about memory?  How would this
>> coincide with rewriting Gnucash/Cutecash as a database app?
>>
>> I would also like to suggest that work on this take a back seat to
>> getting 2.4 out the door.  Boring, yes, but there are lots of bugs in
>> bugzilla.  Can we go through and identify which ones we would like fixed
>> by 2.4?
>>
>
> I'd like to second Phil's comments, with which I agree completely. While I
> don't have any standing as a Gnucash developer, I've worked on and managed
> large software projects for a long time, so I do know something about the
> issues being raised here.
>
> In particular, I think choosing C++ for a UI re-write deserves some
> discussion. Phil raised one of the issues -- lack of memory management. My
> personal opinion of C++ is pretty low -- I think it's far too complex,
> needlessly so (and yes, I've written C++ code myself and read a lot more of
> it, mostly in a pretty horrified state). Yes, I understand that it's widely
> used, but that doesn't mean it's good. I would cite Windows as an example of
> this phenomenon. And while it's widely used, I think it's difficult to find
> people who can write clean, readable, understandable code in C++, something
> that I think is key to a project like this, where code needs to pass easily
> through the eyes and brains of multiple people. So I would urge the Gnucash
> powers-that-be not to view C++ as a default, if there really is a desire to
> move to more modern languages than C. If C++ is ultimately chosen, it should
> only be after careful consideration of all the alternatives.
>

I should have explicitly registered my agreement with Phil about focusing on
getting 2.4 out. It's just over a year since 2.2.9 was released. While I
don't think that's excessive given the nature of the project and the fact
that the database back-end is a big deal,  I think with some focused effort
on QA and bug-fixing, it can be ready for release in the near future. I
think now is exactly the wrong time to get into an attention-diverting
debate about languages and tools. That can and should wait, in my opinion,
until

Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.

2010-03-05 Thread Donald Allen 
On Fri, Mar 5, 2010 at 8:42 AM, Phil Longstaff wrote:

> On Thu, 2010-03-04 at 21:34 +0100, Christian Stimming wrote:
> > I'd like to explain my recent experiments with C++ and cmake: I was tired
> of
> > the amount of code one has to write in the C language to achieve
> seemingly
> > trivial tasks. In my day-time projects with other, more GUI-suited,
> > programming languages, the simple tasks can be written sooo much simpler,
> > leaving much more time for the actual challenging tasks. In gnucash, over
> and
> > over again I thought couldn't the GUI be written in any of the more
> modern
> > languages and/or toolkits. I mean, can we get the fun into gnucash coding
> > again?
> >
> > Actually, we can.
> >
> > Announcing a new sub-project in gnucash: The non-GUI parts are re-used in
> the
> > state they are, in the C language. This means the double-entry principles
> and
> > all of the other achievments in the "engine" and xml-backend and
> eventually
> > other backends can be re-used. But the GUI is rewritten completely new,
> from
> > scratch, in C++ and using the Qt toolkit. Fun again. The build system is
> CMake
> > because its configuration runs magnitudes faster. Fun again. And as a
> final
> > bonus, for MS windows more compiler than before are supported, namely
> this
> > whole new project can be compiled by MS Visual Studio as well. So here it
> is:
> >
> >   Cutecash
> >   Free Finance Software. Easy to develop, easy to use.
> >
>
>
> > Currently this is only a proof-of-concept for developers: You can load an
> > existing gnucash XML file, and it will show the list of accounts as a
> flat
> > table in a QTableView. The fun part is how easy it was to add this
> display of
> > all accounts, so it will probably take only another 1-2 hours until the
> > account list is a tree to be viewed in a QTreeView. And a QTableView with
> the
> > splits of an account can't be far...
> >
> > To give this a try, have qt4 (>=4.5.0) and cmake (>= 2.6.0) installed
> and:
> >
> >   mkdir build-cutecash
> >   cd build-cutecash
> >   cmake ..
> >   make
> >   ./src/gnc/cutecash
> >
> > Have fun (again)!
>
> It doesn't seem able to read any of my XML files.  Oh well.
>
> While this may be/is guaranteed to restart the various language wars
> (can we do this in Visual Basic, please :)), I think it's a great idea -
> use the best tools available for different parts of the code.
>
> Someone (John Ralls?) asked why we would keep the core in C.  Wx vs Qt
> came up.
>
> I'd like to see discussion of why different technologies would be used
> for various parts of the system.  What features does the engine need?
> Why C++ for the UI?  Would we do better with a language using garbage
> collection so that we don't need to worry about memory?  How would this
> coincide with rewriting Gnucash/Cutecash as a database app?
>
> I would also like to suggest that work on this take a back seat to
> getting 2.4 out the door.  Boring, yes, but there are lots of bugs in
> bugzilla.  Can we go through and identify which ones we would like fixed
> by 2.4?
>

I'd like to second Phil's comments, with which I agree completely. While I
don't have any standing as a Gnucash developer, I've worked on and managed
large software projects for a long time, so I do know something about the
issues being raised here.

In particular, I think choosing C++ for a UI re-write deserves some
discussion. Phil raised one of the issues -- lack of memory management. My
personal opinion of C++ is pretty low -- I think it's far too complex,
needlessly so (and yes, I've written C++ code myself and read a lot more of
it, mostly in a pretty horrified state). Yes, I understand that it's widely
used, but that doesn't mean it's good. I would cite Windows as an example of
this phenomenon. And while it's widely used, I think it's difficult to find
people who can write clean, readable, understandable code in C++, something
that I think is key to a project like this, where code needs to pass easily
through the eyes and brains of multiple people. So I would urge the Gnucash
powers-that-be not to view C++ as a default, if there really is a desire to
move to more modern languages than C. If C++ is ultimately chosen, it should
only be after careful consideration of all the alternatives.

/Don



>
> Phil
>
> ___
> 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: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.

2010-03-05 Thread Phil Longstaff 
On Thu, 2010-03-04 at 21:34 +0100, Christian Stimming wrote:
> I'd like to explain my recent experiments with C++ and cmake: I was tired of 
> the amount of code one has to write in the C language to achieve seemingly 
> trivial tasks. In my day-time projects with other, more GUI-suited, 
> programming languages, the simple tasks can be written sooo much simpler, 
> leaving much more time for the actual challenging tasks. In gnucash, over and 
> over again I thought couldn't the GUI be written in any of the more modern 
> languages and/or toolkits. I mean, can we get the fun into gnucash coding 
> again?
> 
> Actually, we can.
> 
> Announcing a new sub-project in gnucash: The non-GUI parts are re-used in the 
> state they are, in the C language. This means the double-entry principles and 
> all of the other achievments in the "engine" and xml-backend and eventually 
> other backends can be re-used. But the GUI is rewritten completely new, from 
> scratch, in C++ and using the Qt toolkit. Fun again. The build system is 
> CMake 
> because its configuration runs magnitudes faster. Fun again. And as a final 
> bonus, for MS windows more compiler than before are supported, namely this 
> whole new project can be compiled by MS Visual Studio as well. So here it is:
> 
>   Cutecash
>   Free Finance Software. Easy to develop, easy to use.
> 


> Currently this is only a proof-of-concept for developers: You can load an 
> existing gnucash XML file, and it will show the list of accounts as a flat 
> table in a QTableView. The fun part is how easy it was to add this display of 
> all accounts, so it will probably take only another 1-2 hours until the 
> account list is a tree to be viewed in a QTreeView. And a QTableView with the 
> splits of an account can't be far...
> 
> To give this a try, have qt4 (>=4.5.0) and cmake (>= 2.6.0) installed and:
> 
>   mkdir build-cutecash
>   cd build-cutecash
>   cmake ..
>   make
>   ./src/gnc/cutecash
> 
> Have fun (again)!

It doesn't seem able to read any of my XML files.  Oh well.

While this may be/is guaranteed to restart the various language wars
(can we do this in Visual Basic, please :)), I think it's a great idea -
use the best tools available for different parts of the code.

Someone (John Ralls?) asked why we would keep the core in C.  Wx vs Qt
came up.

I'd like to see discussion of why different technologies would be used
for various parts of the system.  What features does the engine need?
Why C++ for the UI?  Would we do better with a language using garbage
collection so that we don't need to worry about memory?  How would this
coincide with rewriting Gnucash/Cutecash as a database app?

I would also like to suggest that work on this take a back seat to
getting 2.4 out the door.  Boring, yes, but there are lots of bugs in
bugzilla.  Can we go through and identify which ones we would like fixed
by 2.4?

Phil

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

Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.

2010-03-05 Thread Herbert Thoma 
I appologize for continually replying to my own mails
but I finally made it.

The extern "C" block in main.cpp should not include system includes.

A patch with my changes to make it work is attached.

 Herbert.

Herbert Thoma schrieb:
> Some more experiments:
> 
> Qt 4.4.0 is not sufficient because it does not provide QSharedPointer,
> so I installed Qt 4.6.2 and I inserted a #define HAVE_GUILE18 in
> src/engine/engine-helpers.c. This way everything compiles but the very
> final main.cpp.
> 
> I do not really understand the error:
> 
> [ 99%] Building CXX object src/gnc/CMakeFiles/cutecash.dir/main.cpp.o
> In file included from /usr/include/c++/4.3/iosfwd:46,
>  from /usr/include/gmp.h:24,
>  from /usr/include/libguile.h:24,
>  from 
> /home/tma/gnucash/gnucash_cvs/cutecash/src/gnc/main.cpp:31:
> /usr/include/c++/4.3/bits/stringfwd.h:48: error: template with C linkage
> /usr/include/c++/4.3/bits/stringfwd.h:51: error: template with C linkage
> /usr/include/c++/4.3/bits/stringfwd.h:54: error: template with C linkage
> /usr/include/c++/4.3/bits/stringfwd.h:58: error: template specialization with 
> C linkage
> /usr/include/c++/4.3/bits/stringfwd.h:63: error: template specialization with 
> C linkage
> In file included from /usr/include/c++/4.3/iosfwd:47,
>  from /usr/include/gmp.h:24,
>  from /usr/include/libguile.h:24,
>  from 
> /home/tma/gnucash/gnucash_cvs/cutecash/src/gnc/main.cpp:31:
> /usr/include/c++/4.3/bits/postypes.h:90: error: template with C linkage
> /usr/include/c++/4.3/bits/postypes.h:193: error: template with C linkage
> /usr/include/c++/4.3/bits/postypes.h:198: error: template with C linkage
> In file included from /usr/include/gmp.h:24,
>  from /usr/include/libguile.h:24,
>  from 
> /home/tma/gnucash/gnucash_cvs/cutecash/src/gnc/main.cpp:31:
> /usr/include/c++/4.3/iosfwd:51: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:54: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:57: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:60: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:63: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:66: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:70: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:74: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:78: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:82: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:85: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:88: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:91: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:94: error: template with C linkage
> /usr/include/c++/4.3/iosfwd:97: error: template with C linkage
> In file included from /usr/include/libguile.h:24,
>  from 
> /home/tma/gnucash/gnucash_cvs/cutecash/src/gnc/main.cpp:31:
> /usr/include/gmp.h:2136: error: declaration of C function ‘std::ostream& 
> operator<<(std::ostream&, const __mpq_struct*)’ conflicts with
> /usr/include/gmp.h:2135: error: previous declaration ‘std::ostream& 
> operator<<(std::ostream&, const __mpz_struct*)’ here
> /usr/include/gmp.h:2137: error: declaration of C function ‘std::ostream& 
> operator<<(std::ostream&, const __mpf_struct*)’ conflicts with
> /usr/include/gmp.h:2136: error: previous declaration ‘std::ostream& 
> operator<<(std::ostream&, const __mpq_struct*)’ here
> /usr/include/gmp.h:2139: error: declaration of C function ‘std::istream& 
> operator>>(std::istream&, __mpq_struct*)’ conflicts with
> /usr/include/gmp.h:2138: error: previous declaration ‘std::istream& 
> operator>>(std::istream&, __mpz_struct*)’ here
> /usr/include/gmp.h:2140: error: declaration of C function ‘std::istream& 
> operator>>(std::istream&, __mpf_struct*)’ conflicts with
> /usr/include/gmp.h:2139: error: previous declaration ‘std::istream& 
> operator>>(std::istream&, __mpq_struct*)’ here
> make[2]: *** [src/gnc/CMakeFiles/cutecash.dir/main.cpp.o] Fehler 1
> make[1]: *** [src/gnc/CMakeFiles/cutecash.dir/all] Fehler 2
> make: *** [all] Fehler 2
> 
>  Herbert.
> 
> Herbert Thoma schrieb:
>> Hi Christian,
>>
>> cool project! I tried to build cutecash and ran into some problems:
>>
>> I run SuSE 11.0 on this computer. SuSE 11.0 is not so old, however, it
>> lacks your required minimum versions of glib and Qt.
>> You require glib (and gobject, gmodule, gthread) 2.20.0 but GnuCash
>> only requires 2.12.0.
>> You require Qt 4.5.0 but I have only 4.4.0.
>> I changed the minimum requirements in CMakeLists.txt to glib 2.12.0
>> and Qt 4.4.0 and cmake completed successfully.
>>
>> Compiling fails with the following error:
>> [ 62%] Building C object src/engine/CMakeFiles/engine.dir/engine-helpers.c.o
>> /home/tma/gnucash/gnucash_cvs/cutecash/src/engine/engine-helpers.c: In 
>> function ‘gnc_query2scm’:
>>

Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.

2010-03-05 Thread Christian Stimming 

Hi Herbert,

thanks for the feedback. I will happily commit reduced version  
requirements; however, I started the project with relatively high  
requirements on purpose because those were the versions I tested with,  
so I couldn't give any guarantees with older versions. If you provide  
me with other sufficient numbers, I will commit them, just as what you  
wrote in your previous message.


Zitat von Herbert Thoma :

I do not really understand the error:

[ 99%] Building CXX object src/gnc/CMakeFiles/cutecash.dir/main.cpp.o
In file included from /usr/include/c++/4.3/iosfwd:46,
 from /usr/include/gmp.h:24,
 from /usr/include/libguile.h:24,
 from  
/home/tma/gnucash/gnucash_cvs/cutecash/src/gnc/main.cpp:31:

/usr/include/c++/4.3/bits/stringfwd.h:48: error: template with C linkage


To fix this, add a #include  in main.cpp *before*  
(outside) the extern "C" section.


Apparently some brain-dead developers decided to have the   
header include some C++ headers as well, conditioned on #ifdef  
__cplusplus. This contradicts my assumption that I'm including the  
gnucash C-only headers, which in turn requires the surrounding extern  
"C", but this works only if the consecutively included dependency  
headers are C-only as well.  breaks this assumption, which is  
very stupid of the gmp guys. Grrr.


I didn't see this error because I was using guile-1.6 and apparently  
that one doesn't include  anywhere. Thanks for posting it here.  
Feel free to send me a patch of all your changes later today (I might  
have SVN access tonight again).


Regards,

Christian

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

Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.

2010-03-05 Thread Herbert Thoma 
Some more experiments:

Qt 4.4.0 is not sufficient because it does not provide QSharedPointer,
so I installed Qt 4.6.2 and I inserted a #define HAVE_GUILE18 in
src/engine/engine-helpers.c. This way everything compiles but the very
final main.cpp.

I do not really understand the error:

[ 99%] Building CXX object src/gnc/CMakeFiles/cutecash.dir/main.cpp.o
In file included from /usr/include/c++/4.3/iosfwd:46,
 from /usr/include/gmp.h:24,
 from /usr/include/libguile.h:24,
 from 
/home/tma/gnucash/gnucash_cvs/cutecash/src/gnc/main.cpp:31:
/usr/include/c++/4.3/bits/stringfwd.h:48: error: template with C linkage
/usr/include/c++/4.3/bits/stringfwd.h:51: error: template with C linkage
/usr/include/c++/4.3/bits/stringfwd.h:54: error: template with C linkage
/usr/include/c++/4.3/bits/stringfwd.h:58: error: template specialization with C 
linkage
/usr/include/c++/4.3/bits/stringfwd.h:63: error: template specialization with C 
linkage
In file included from /usr/include/c++/4.3/iosfwd:47,
 from /usr/include/gmp.h:24,
 from /usr/include/libguile.h:24,
 from 
/home/tma/gnucash/gnucash_cvs/cutecash/src/gnc/main.cpp:31:
/usr/include/c++/4.3/bits/postypes.h:90: error: template with C linkage
/usr/include/c++/4.3/bits/postypes.h:193: error: template with C linkage
/usr/include/c++/4.3/bits/postypes.h:198: error: template with C linkage
In file included from /usr/include/gmp.h:24,
 from /usr/include/libguile.h:24,
 from 
/home/tma/gnucash/gnucash_cvs/cutecash/src/gnc/main.cpp:31:
/usr/include/c++/4.3/iosfwd:51: error: template with C linkage
/usr/include/c++/4.3/iosfwd:54: error: template with C linkage
/usr/include/c++/4.3/iosfwd:57: error: template with C linkage
/usr/include/c++/4.3/iosfwd:60: error: template with C linkage
/usr/include/c++/4.3/iosfwd:63: error: template with C linkage
/usr/include/c++/4.3/iosfwd:66: error: template with C linkage
/usr/include/c++/4.3/iosfwd:70: error: template with C linkage
/usr/include/c++/4.3/iosfwd:74: error: template with C linkage
/usr/include/c++/4.3/iosfwd:78: error: template with C linkage
/usr/include/c++/4.3/iosfwd:82: error: template with C linkage
/usr/include/c++/4.3/iosfwd:85: error: template with C linkage
/usr/include/c++/4.3/iosfwd:88: error: template with C linkage
/usr/include/c++/4.3/iosfwd:91: error: template with C linkage
/usr/include/c++/4.3/iosfwd:94: error: template with C linkage
/usr/include/c++/4.3/iosfwd:97: error: template with C linkage
In file included from /usr/include/libguile.h:24,
 from 
/home/tma/gnucash/gnucash_cvs/cutecash/src/gnc/main.cpp:31:
/usr/include/gmp.h:2136: error: declaration of C function ‘std::ostream& 
operator<<(std::ostream&, const __mpq_struct*)’ conflicts with
/usr/include/gmp.h:2135: error: previous declaration ‘std::ostream& 
operator<<(std::ostream&, const __mpz_struct*)’ here
/usr/include/gmp.h:2137: error: declaration of C function ‘std::ostream& 
operator<<(std::ostream&, const __mpf_struct*)’ conflicts with
/usr/include/gmp.h:2136: error: previous declaration ‘std::ostream& 
operator<<(std::ostream&, const __mpq_struct*)’ here
/usr/include/gmp.h:2139: error: declaration of C function ‘std::istream& 
operator>>(std::istream&, __mpq_struct*)’ conflicts with
/usr/include/gmp.h:2138: error: previous declaration ‘std::istream& 
operator>>(std::istream&, __mpz_struct*)’ here
/usr/include/gmp.h:2140: error: declaration of C function ‘std::istream& 
operator>>(std::istream&, __mpf_struct*)’ conflicts with
/usr/include/gmp.h:2139: error: previous declaration ‘std::istream& 
operator>>(std::istream&, __mpq_struct*)’ here
make[2]: *** [src/gnc/CMakeFiles/cutecash.dir/main.cpp.o] Fehler 1
make[1]: *** [src/gnc/CMakeFiles/cutecash.dir/all] Fehler 2
make: *** [all] Fehler 2

 Herbert.

Herbert Thoma schrieb:
> Hi Christian,
> 
> cool project! I tried to build cutecash and ran into some problems:
> 
> I run SuSE 11.0 on this computer. SuSE 11.0 is not so old, however, it
> lacks your required minimum versions of glib and Qt.
> You require glib (and gobject, gmodule, gthread) 2.20.0 but GnuCash
> only requires 2.12.0.
> You require Qt 4.5.0 but I have only 4.4.0.
> I changed the minimum requirements in CMakeLists.txt to glib 2.12.0
> and Qt 4.4.0 and cmake completed successfully.
> 
> Compiling fails with the following error:
> [ 62%] Building C object src/engine/CMakeFiles/engine.dir/engine-helpers.c.o
> /home/tma/gnucash/gnucash_cvs/cutecash/src/engine/engine-helpers.c: In 
> function ‘gnc_query2scm’:
> /home/tma/gnucash/gnucash_cvs/cutecash/src/engine/engine-helpers.c:1712: 
> error: ‘scm_block_gc’ undeclared (first use in this function)
> /home/tma/gnucash/gnucash_cvs/cutecash/src/engine/engine-helpers.c:1712: 
> error: (Each undeclared identifier is reported only once
> /home/tma/gnucash/gnucash_cvs/cutecash/src/engine/engine-helpers.c:1712: 
> error: for each function it appears in.)
> /home

Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.

2010-03-05 Thread Herbert Thoma 
Hi Christian,

cool project! I tried to build cutecash and ran into some problems:

I run SuSE 11.0 on this computer. SuSE 11.0 is not so old, however, it
lacks your required minimum versions of glib and Qt.
You require glib (and gobject, gmodule, gthread) 2.20.0 but GnuCash
only requires 2.12.0.
You require Qt 4.5.0 but I have only 4.4.0.
I changed the minimum requirements in CMakeLists.txt to glib 2.12.0
and Qt 4.4.0 and cmake completed successfully.

Compiling fails with the following error:
[ 62%] Building C object src/engine/CMakeFiles/engine.dir/engine-helpers.c.o
/home/tma/gnucash/gnucash_cvs/cutecash/src/engine/engine-helpers.c: In function 
‘gnc_query2scm’:
/home/tma/gnucash/gnucash_cvs/cutecash/src/engine/engine-helpers.c:1712: error: 
‘scm_block_gc’ undeclared (first use in this function)
/home/tma/gnucash/gnucash_cvs/cutecash/src/engine/engine-helpers.c:1712: error: 
(Each undeclared identifier is reported only once
/home/tma/gnucash/gnucash_cvs/cutecash/src/engine/engine-helpers.c:1712: error: 
for each function it appears in.)
/home/tma/gnucash/gnucash_cvs/cutecash/src/engine/engine-helpers.c: In function 
‘gnc_scm2query_v2’:
/home/tma/gnucash/gnucash_cvs/cutecash/src/engine/engine-helpers.c:2013: error: 
‘scm_block_gc’ undeclared (first use in this function)
make[2]: *** [src/engine/CMakeFiles/engine.dir/engine-helpers.c.o] Fehler 1
make[1]: *** [src/engine/CMakeFiles/engine.dir/all] Fehler 2
make: *** [all] Fehler 2

The problem are some section like this:
#ifndef HAVE_GUILE18
--scm_block_gc;
#endif
in src/engine/engine-helpers.c

Do you know how to check for the guile version and how to set the HAVE_GUILE18 
if required
in cmake?

Keep up this interesting work!

 Herbert.

Christian Stimming schrieb:
> I'd like to explain my recent experiments with C++ and cmake: I was tired of 
> the amount of code one has to write in the C language to achieve seemingly 
> trivial tasks. In my day-time projects with other, more GUI-suited, 
> programming languages, the simple tasks can be written sooo much simpler, 
> leaving much more time for the actual challenging tasks. In gnucash, over and 
> over again I thought couldn't the GUI be written in any of the more modern 
> languages and/or toolkits. I mean, can we get the fun into gnucash coding 
> again?
> 
> Actually, we can.
> 
> Announcing a new sub-project in gnucash: The non-GUI parts are re-used in the 
> state they are, in the C language. This means the double-entry principles and 
> all of the other achievments in the "engine" and xml-backend and eventually 
> other backends can be re-used. But the GUI is rewritten completely new, from 
> scratch, in C++ and using the Qt toolkit. Fun again. The build system is 
> CMake 
> because its configuration runs magnitudes faster. Fun again. And as a final 
> bonus, for MS windows more compiler than before are supported, namely this 
> whole new project can be compiled by MS Visual Studio as well. So here it is:
> 
>   Cutecash
>   Free Finance Software. Easy to develop, easy to use.
> 
> Currently this is only a proof-of-concept for developers: You can load an 
> existing gnucash XML file, and it will show the list of accounts as a flat 
> table in a QTableView. The fun part is how easy it was to add this display of 
> all accounts, so it will probably take only another 1-2 hours until the 
> account list is a tree to be viewed in a QTreeView. And a QTableView with the 
> splits of an account can't be far...
> 
> To give this a try, have qt4 (>=4.5.0) and cmake (>= 2.6.0) installed and:
> 
>   mkdir build-cutecash
>   cd build-cutecash
>   cmake ..
>   make
>   ./src/gnc/cutecash
> 
> Have fun (again)!
> 
> Christian
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 

-- 
Herbert Thoma
Dipl.-Ing., MBA
Head of Video Group
Multimedia Realtime Systems Department
Fraunhofer IIS
Am Wolfsmantel 33, 91058 Erlangen, Germany
Phone: +49-9131-776-6130
Fax:   +49-9131-776-6099
email: t...@iis.fhg.de
www: http://www.iis.fhg.de/
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel