Confusion about use of G2

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Confusion about use of G2

Chris Shoemaker
Hey folks,

        I'm hoping someone can clarify for me a confusion about the
state of the G2 branch.  My understanding was basically that G2 was
feature-frozen like an "rc" kernel - "get what's there working" -
"bug-fixes only" - whatever you want to call it.

        Now I understand any such policy is merely an ideal whose
actual application must also consider many practicalities.
Nevertheless, I've been sitting on a stable, complete implementation
of budgeting since the spring, (I actually use it for my own
budgeting.) along with lots of other general improvements to
e.g. tracing, testing, debugging, etc.  As soon as G2 is released and
a "dev" branch opens I was planning on pushing for inclusion(^).

        Since then, I've also made substantial progress on a
register-rewrite using the GtkTreeModel API.  It's been easier than I
thought. (Although I've made no progress in the past 2 months - no
time.)

        Now, I figured it wouldn't be that tough to maintain these
patches (about a dozen) out-of-tree, and tools like 'quilt' have sure
helped.  But, there has been a lot more patch breakage than I
expected.  Of course, that means more time spent refreshing.  It has
noticeably diminished my time available for new dev work.

        Now, honestly, even though I have a *MUCH* better
understanding of GC's code base than I used to, (It actually feels
comfortably familiar these days.) there's still stuff I just don't
understand because I haven't looked into it.  However, I'm starting to
see that much of the patch breakage isn't from bug-fixes but from new
functionality/improved architecture.

        Ok, let me be very clear: I'M ALL IN FAVOR of improved
architecture.  But...  I don't want to maintain out-of-tree patches
against a tree that's undergoing architectural improvements.  If G2 is
a "dev" branch, then I should have pushed for submission of many
patches a LONG time ago (my fault).  If G2 is a "bug-fix-only" branch,
then it shouldn't slow me down so much to keep my patches fresh
against G2.

        So, which is it?  Neil's tracing patch naturally breaks almost
every patch I have - not to mention the trace system improvements I've
been sitting on until G2 was released.  Should I smack my forehead,
refresh my patches and push for inclusion, clearing my decks to get
back to the register-rewrite?  Or, can we open another branch for new
development?  Or, can we just decide not to make wonderful
architectural improvements(*) in G2?  

-chris

(^) I know there's an incomplete budget in G2, I was expecting it to
be removed for G2.  Incidentally, I believe my budget implementation
should be easier to integrate with QOF than the existing
implementation, since it defines fewer object types.

(*) I know *some* architectural improvements are necessary to make G2
work, but is QOF one of them?!  The more I understand about QOF, the
less essential to a quick release it seems.  (I'm ok with a G2 release
with only XML file backend.)
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Neil Williams-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Shoemaker wrote:
|         I'm hoping someone can clarify for me a confusion about the
| state of the G2 branch.  My understanding was basically that G2 was
| feature-frozen like an "rc" kernel - "get what's there working" -
| "bug-fixes only" - whatever you want to call it.

? It's a branch for code that requires Gnome2.

|         Now I understand any such policy is merely an ideal whose
| actual application must also consider many practicalities.

One of which is spinning out QOF.

This patch has gone a long way to achieving that but more needs to be done.

|         Now, I figured it wouldn't be that tough to maintain these
| patches (about a dozen) out-of-tree, and tools like 'quilt' have sure
| helped.

I'll have to find some time to look at quilt - it could help with my own
patches that are needed to build gnucash on OSX and Debian.

|  But, there has been a lot more patch breakage than I
| expected.  Of course, that means more time spent refreshing.  It has
| noticeably diminished my time available for new dev work.

I get the same with all the GOffice code and it's dependencies. Then OSX
has horrible problems with the frequent use of -module in the makefiles.

|         Ok, let me be very clear: I'M ALL IN FAVOR of improved
| architecture.  But...  I don't want to maintain out-of-tree patches
| against a tree that's undergoing architectural improvements.  If G2 is
| a "dev" branch, then I should have pushed for submission of many
| patches a LONG time ago (my fault).  If G2 is a "bug-fix-only" branch,
| then it shouldn't slow me down so much to keep my patches fresh
| against G2.

The tag is gnucash-gnome2-dev so it is a "dev" branch - that's my
understanding.

|         So, which is it?  Neil's tracing patch naturally breaks almost
| every patch I have - not to mention the trace system improvements I've
| been sitting on until G2 was released.

I wish you'd said something when I started talking about trace changes
on this list. Are these changes compatible with using trace via the
external QOF library?

However, the fix for your out-of-tree code could be a copy of how over
250 other files have had to be changed from a short int identifier to a
const gchar* identifier string.

| (*) I know *some* architectural improvements are necessary to make G2
| work, but is QOF one of them?!  The more I understand about QOF, the
| less essential to a quick release it seems.  (I'm ok with a G2 release
| with only XML file backend.)

QOF needs a stable release imminently for use by other applications. It
is already on pre-release. Gnucash needs to use QOF as an external
library. There shouldn't be too many changes left to make - the backend
is the main one, changing from gnc-module and scheme to GModule and
dlopen. It's working in cashutil, but I stopped short of putting it into
this commit.

Then there are the changes required to work with cashutil - again these
are architectural changes to libraries and makefiles, as well as the
abstraction of the GUI logic into a library to be shared with cashutil.

I've got a usable undo framework out-of-tree and it will stay there for
now. I'll also be implementing the logic abstraction out-of-tree. I
can't introduce those to the gnucash tree until gnucash itself is closer
to accepting cashutil which in turn requires a completed QOF spinout.

- --

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDP5epk7DVr6iX/QIRArvBAJ9+2bE+CdjgEGFuwlbgzq+Ka09ARwCfWzg5
eFyXxNgiTxkTy/z6VYccuCI=
=VsBU
-----END PGP SIGNATURE-----
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Josh Sled
In reply to this post by Chris Shoemaker
On Sat, 2005-10-01 at 16:59 -0400, Chris Shoemaker wrote:
>         I'm hoping someone can clarify for me a confusion about the
> state of the G2 branch.  My understanding was basically that G2 was
> feature-frozen like an "rc" kernel - "get what's there working" -
> "bug-fixes only" - whatever you want to call it.

That's more or less my understanding, but it's an informal one, true.
The goal is strictly and specifically to get gnucash working with
as-close-to-feature parity with 1.8 under gtk/gnome2.  That's taken some
interesting twists (gog, gconf), but those are basically in support of
the above.

We need to get to a G2-supporting release as quickly as possible.


> patches a LONG time ago (my fault).  If G2 is a "bug-fix-only" branch,
> then it shouldn't slow me down so much to keep my patches fresh
> against G2.

Well, with respect to the scope of commits, it's not exactly a
"bug-fix-only" branch, but it's not a "dev" branch either.  There's some
larger-than-a-bug-fix work to be done; neither QOF-pullout nor
register-rewrite-in-gtk would be on my draft of that change-list,
though.

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Chris Shoemaker
On Sun, Oct 02, 2005 at 01:08:37PM -0400, Josh Sled wrote:

> On Sat, 2005-10-01 at 16:59 -0400, Chris Shoemaker wrote:
> >         I'm hoping someone can clarify for me a confusion about the
> > state of the G2 branch.  My understanding was basically that G2 was
> > feature-frozen like an "rc" kernel - "get what's there working" -
> > "bug-fixes only" - whatever you want to call it.
>
> That's more or less my understanding, but it's an informal one, true.
> The goal is strictly and specifically to get gnucash working with
> as-close-to-feature parity with 1.8 under gtk/gnome2.  That's taken some
> interesting twists (gog, gconf), but those are basically in support of
> the above.
>
> We need to get to a G2-supporting release as quickly as possible.
>
>
> > patches a LONG time ago (my fault).  If G2 is a "bug-fix-only" branch,
> > then it shouldn't slow me down so much to keep my patches fresh
> > against G2.
>
> Well, with respect to the scope of commits, it's not exactly a
> "bug-fix-only" branch, but it's not a "dev" branch either.  There's some
> larger-than-a-bug-fix work to be done; neither QOF-pullout nor
> register-rewrite-in-gtk would be on my draft of that change-list,
> though.

Right. I thought that the "larger-than-a-bug-fix" work was basically
compensating for obsolete dependencies.  I agree about
register-rewrite.  Could you explain what you consider to be
QOF-pullout?  I mean, how much QOF work is needed to get a
G2-supporting release ASAP?  This stuff isn't motivated in
GNOME2_STATUS.

-chris

>
> ...jsled
> --
> http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Josh Sled
On Sun, 2005-10-02 at 14:28 -0400, Chris Shoemaker wrote:
> Right. I thought that the "larger-than-a-bug-fix" work was basically
> compensating for obsolete dependencies.  I agree about
> register-rewrite.  Could you explain what you consider to be
> QOF-pullout?  I mean, how much QOF work is needed to get a
> G2-supporting release ASAP?  This stuff isn't motivated in
> GNOME2_STATUS.

Gnucash currently depends on a copy of QOF which was birthed inside
gnucash itself.  QOF should become an independent library, which gnucash
then depends on as any other caller.  The extrication of QOF involves
changing some facilities at the border of the two.

A good example is the gnc-trace.c-defined logging and module stuff,
which is presently gnucash-specific, but really should be part of QOF.

I'm sure that I'm not sure about all of the details of it; perhaps Neil
can breifly summarize what's left.  I don't believe that it relates to
the G2 port at all.

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Chris Shoemaker
In reply to this post by Neil Williams-2
On Sun, Oct 02, 2005 at 09:17:46AM +0100, Neil Williams wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Chris Shoemaker wrote:
> |         I'm hoping someone can clarify for me a confusion about the
> | state of the G2 branch.  My understanding was basically that G2 was
> | feature-frozen like an "rc" kernel - "get what's there working" -
> | "bug-fixes only" - whatever you want to call it.
>
> ? It's a branch for code that requires Gnome2.
>
> |         Now I understand any such policy is merely an ideal whose
> | actual application must also consider many practicalities.
>
> One of which is spinning out QOF.

Care to explain that?  I was more thinking about practicalities such
as developer time and efficiency.

>
> This patch has gone a long way to achieving that but more needs to be done.
>
> |         Now, I figured it wouldn't be that tough to maintain these
> | patches (about a dozen) out-of-tree, and tools like 'quilt' have sure
> | helped.
>
> I'll have to find some time to look at quilt - it could help with my own
> patches that are needed to build gnucash on OSX and Debian.

I recommend it.

>
> |  But, there has been a lot more patch breakage than I
> | expected.  Of course, that means more time spent refreshing.  It has
> | noticeably diminished my time available for new dev work.
>
> I get the same with all the GOffice code and it's dependencies. Then OSX
> has horrible problems with the frequent use of -module in the makefiles.

You get massive patch breaking due to code churn?!?  What code has
been churning under you? Surely not GOG.

>
> |         Ok, let me be very clear: I'M ALL IN FAVOR of improved
> | architecture.  But...  I don't want to maintain out-of-tree patches
> | against a tree that's undergoing architectural improvements.  If G2 is
> | a "dev" branch, then I should have pushed for submission of many
> | patches a LONG time ago (my fault).  If G2 is a "bug-fix-only" branch,
> | then it shouldn't slow me down so much to keep my patches fresh
> | against G2.
>
> The tag is gnucash-gnome2-dev so it is a "dev" branch - that's my
> understanding.

Sorry, this is not a convincing argument.

>
> |         So, which is it?  Neil's tracing patch naturally breaks almost
> | every patch I have - not to mention the trace system improvements I've
> | been sitting on until G2 was released.
>
> I wish you'd said something when I started talking about trace changes
> on this list. Are these changes compatible with using trace via the
> external QOF library?

Some are.  Some aren't.

>
> However, the fix for your out-of-tree code could be a copy of how over
> 250 other files have had to be changed from a short int identifier to a
> const gchar* identifier string.

Of course.

>
> | (*) I know *some* architectural improvements are necessary to make G2
> | work, but is QOF one of them?!  The more I understand about QOF, the
> | less essential to a quick release it seems.  (I'm ok with a G2 release
> | with only XML file backend.)
>
> QOF needs a stable release imminently for use by other applications. It
> is already on pre-release. Gnucash needs to use QOF as an external
> library. There shouldn't be too many changes left to make - the backend
> is the main one, changing from gnc-module and scheme to GModule and
> dlopen. It's working in cashutil, but I stopped short of putting it into
> this commit.

There might be a logical leap here.

1) QOF needs release imminently.  [ Let's take this as a given. ]

2) GC needs to use QOF as external library.  
    [ I'm not exactly sure how strong a need I would admit, but let's
assume this is completely true. ]

3) Therefore, GC needs, in the next G2 release, all these
architectural changes to support the new release of QOF.

I don't see 3) following from 1) and 2), but feel free to make the
case.

Don't assume that everyone knows what you know about the wonderful
benefits of QOF.  Please explain why G2 can't be released, with
feature parity with "G1", without architectural improvements.  Note
that it's not enough to simply explain how great QOF is for GC.  Lots
of things are great for GC that won't be in the first release of G2.
Why should all these QOF changes?

>
> Then there are the changes required to work with cashutil - again these
> are architectural changes to libraries and makefiles, as well as the
> abstraction of the GUI logic into a library to be shared with cashutil.

Again, fine, let's assume cashutil is wonderful.  Do we have to make
architectural changes to G2 to work with cashutil in order to achieve
feature parity?

>
> I've got a usable undo framework out-of-tree and it will stay there for
> now. I'll also be implementing the logic abstraction out-of-tree. I
> can't introduce those to the gnucash tree until gnucash itself is closer
> to accepting cashutil which in turn requires a completed QOF spinout.

[I'm assuming you're thinking post-G2 release here.]  So you *do* see
a distinction between architectural changes that should wait until
after G2 is released and those that are necessary now?  Could you
explain what that distinction is?

Thanks.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Chris Shoemaker
In reply to this post by Josh Sled
On Sun, Oct 02, 2005 at 02:42:54PM -0400, Josh Sled wrote:

> On Sun, 2005-10-02 at 14:28 -0400, Chris Shoemaker wrote:
> > Right. I thought that the "larger-than-a-bug-fix" work was basically
> > compensating for obsolete dependencies.  I agree about
> > register-rewrite.  Could you explain what you consider to be
> > QOF-pullout?  I mean, how much QOF work is needed to get a
> > G2-supporting release ASAP?  This stuff isn't motivated in
> > GNOME2_STATUS.
>
> Gnucash currently depends on a copy of QOF which was birthed inside
> gnucash itself.  QOF should become an independent library, which gnucash
> then depends on as any other caller.  The extrication of QOF involves
> changing some facilities at the border of the two.
>
> A good example is the gnc-trace.c-defined logging and module stuff,
> which is presently gnucash-specific, but really should be part of QOF.
>
> I'm sure that I'm not sure about all of the details of it; perhaps Neil
> can breifly summarize what's left.  I don't believe that it relates to
> the G2 port at all.

Then why is it happening in the G2 branch?!!  I want to base my
patches on the tree that will only be moving toward a
feature-comparable G2 release, not a tree that is moving toward a QOF
factoring.

How would David like it if I were doing the register rewrite in the
tree he was trying to release?  How is QOF pullout any different?

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Neil Williams-2
In reply to this post by Josh Sled
On Sunday 02 October 2005 7:42 pm, Josh Sled wrote:
> On Sun, 2005-10-02 at 14:28 -0400, Chris Shoemaker wrote:
> Gnucash currently depends on a copy of QOF which was birthed inside
> gnucash itself.

Yes, originally it was QOF 0.5.0 and is now close to 0.6.0. The remaining
differences are:
qofbackend: Code is almost ready and is currently in testing/use in cashutil
to convert all file backend access from gnc-module to GModule. GModule is
glib-2 dependent. I need to look at how this will fit with the postgres
backend which I don't want to have to change if I can avoid it.

> QOF should become an independent library, which gnucash
> then depends on as any other caller.  The extrication of QOF involves
> changing some facilities at the border of the two.

The largest of which has been done, albeit not as cleanly as intended.

> A good example is the gnc-trace.c-defined logging and module stuff,
> which is presently gnucash-specific, but really should be part of QOF.

That's what has just been changed. The code just committed is no longer
reliant on gnucash in any way. It also caused the majority of gnucash files
to use #include "qof.h" in place of nearly all private QOF headers that will
not be accessible from the library. There is one remaining issue which I've
highlighted with a \todo in the Doxygen output and which I will look at
fixing once the backend is fixed.

> I'm sure that I'm not sure about all of the details of it; perhaps Neil
> can breifly summarize what's left.

The QofBackend to use GModule. I didn't put that in the current patch but it
is working in cashutil. This does need to be fixed because the current mix is
causing error messages when trying to use QSF.

There may well be other smaller issues but I cannot test with the external QOF
library until the backend issue is fixed.

> I don't believe that it relates to
> the G2 port at all.

I agree none of the QOF stuff is related to the GUI port to Gtk2 but it is all
related to the underlying port to glib-2.

The original desire for a G2 port, in my understanding, was to port gnucash to
the gnome2 libraries, not just port the GUI to Gtk2.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Chris Shoemaker
On Sun, Oct 02, 2005 at 08:09:16PM +0100, Neil Williams wrote:
> On Sunday 02 October 2005 7:42 pm, Josh Sled wrote:
> > I don't believe that it relates to
> > the G2 port at all.
>
> I agree none of the QOF stuff is related to the GUI port to Gtk2 but it is all
> related to the underlying port to glib-2.
>
> The original desire for a G2 port, in my understanding, was to port gnucash to
> the gnome2 libraries, not just port the GUI to Gtk2.

That's my understanding as well.  So, what functionality in glib1 is
missing from glib2 that requires the QOF pullout?  Is this a tree-sync
issue? i.e.: external QOF has moved forward to version w/o glib1,
therefore the easiest way to remove glib1 dep from gc is to upgrade
internal qof to new version, which requires massive factoring?

-chris

>
> --
>
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
>



> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Neil Williams-2
In reply to this post by Chris Shoemaker
On Sunday 02 October 2005 7:46 pm, Chris Shoemaker wrote:
> > |         Now I understand any such policy is merely an ideal whose
> > | actual application must also consider many practicalities.
> >
> > One of which is spinning out QOF.
>
> Care to explain that?  I was more thinking about practicalities such
> as developer time and efficiency.

1. Removing scheme/guile from the engine code - an inherent task within
spinning out QOF, two sides of the same coin.

2. Not to put too fine a point on it, my developer time copying QOF files into
GnuCash each time it needs an update! Gnucash is benefitting from wider use
of QOF and will benefit much, much more as cashutil develops. I know that
probably doesn't matter to you but it does to me.

3. In terms of user experience and expectation in G2, QSF exports and QOF
merge will provide solutions to real user problems relating to data import,
export, mining and customised report generation. The GUI code to get the best
out of QSF is not all in place but there is sufficient - particularly with
the business features - to make it very useful. Adding similar commands to
export accounts and transactions between specified dates into QSF is a small
task - it depends on how other things pan out.

If you limit it to an empty feature-parity then this last fix for the error
logging and finishing the fix to the backend load method are the only
remaining QOF tasks. The rest of the code is already in place and has been
for some weeks.

> > I get the same with all the GOffice code and it's dependencies. Then OSX
> > has horrible problems with the frequent use of -module in the makefiles.
>
> You get massive patch breaking due to code churn?!?  What code has
> been churning under you? Surely not GOG.

The goffice code in the gnucash tree hasn't necessarily changed, but the
dependencies of that code HAS changed, that's why I have several patches for
files under lib/goffice to allow it to compile. I'll be looking at using
external GOffice libraries soon - should have done it earlier but had to get
QOF ready for pre-release.

> > I wish you'd said something when I started talking about trace changes
> > on this list. Are these changes compatible with using trace via the
> > external QOF library?
>
> Some are.  Some aren't.

So what are the benefits of your trace changes? What do they cover?

> There might be a logical leap here.
>
> 1) QOF needs release imminently.  [ Let's take this as a given. ]
>
> 2) GC needs to use QOF as external library.
>     [ I'm not exactly sure how strong a need I would admit, but let's
> assume this is completely true. ]
>
> 3) Therefore, GC needs, in the next G2 release, all these
> architectural changes to support the new release of QOF.
>
> I don't see 3) following from 1) and 2), but feel free to make the
> case.
1. GC needs the backend to be fixed. There is a working fix out-of-tree but it
needs to be fitted into GC.
2. I anticipate that remaining issues should be small and therefore it is
worthwhile seeing if G2 can work with an external QOF once the backend is
fixed. I see no point in releasing G2 with an internal QOF library that is
maybe 99% identical to 0.6.0. I really do feel that once the backend is
fixed, the remaining work is that small. This last patch achieved a massive
amount of progress on separating QOF from gnucash. It could (should) have
been done a long time ago.

> Don't assume that everyone knows what you know about the wonderful
> benefits of QOF.

My motivation at the moment is simply to avoid duplicate code. Whenever
possible, G2 should be allowed to use an external QOF library that will be
available before G2 and which contains virtually identical code.

> Please explain why G2 can't be released, with
> feature parity with "G1", without architectural improvements.

The only remaining problem is that in the backend. I expect to be able to fix
that in the next two weeks (I'm away most of next week). The current gnc-
code is not working properly.

There are also architectural changes to the makefiles for libraries that use
-module for G2 to work on Mac OSX. Those warnings that we all see about
linking executables against ... library not beng portable - those warnings
bite on OSX and those were not a problem with the 1.8 tree (I think due to
the version of gcc available for 1.8). They will, however, halt the build of
any G2 package if not fixed.

A relatively minor change that I need to be able to test and then implement.

> Note
> that it's not enough to simply explain how great QOF is for GC.  Lots
> of things are great for GC that won't be in the first release of G2.
> Why should all these QOF changes?

1. To make use of the gnome2 architecture at the level of glib.

2. To prevent duplicate code - I will do everything I can to allow G2 to go
into at least Debian with an external QOF dependency. I have completed the
vast majority of that work, I only have a few fixes left to implement. After
that, libqof1 will remain API compatible for some time so gnucash can make
subsequent releases without problems or synchronisation. It's just that there
have been so many changes from QOF 0.5 to QOF 0.6, it's all a little fraught
at the moment.

> > Then there are the changes required to work with cashutil - again these
> > are architectural changes to libraries and makefiles, as well as the
> > abstraction of the GUI logic into a library to be shared with cashutil.
>
> Again, fine, let's assume cashutil is wonderful.  Do we have to make
> architectural changes to G2 to work with cashutil in order to achieve
> feature parity?

No. cashutil is completely separate, it has helped me fix the backend problem
but it's main contribution won't be visible for a time after QOF 0.6 and G2.
I could not have started cashutil without the work I've done already for QOF
and the new pilot-QOF application.

> > I've got a usable undo framework out-of-tree and it will stay there for
> > now. I'll also be implementing the logic abstraction out-of-tree. I
> > can't introduce those to the gnucash tree until gnucash itself is closer
> > to accepting cashutil which in turn requires a completed QOF spinout.
>
> [I'm assuming you're thinking post-G2 release here.]

Yes, principally because cashutil requires large amounts of new or relocated
code to implement the logic. That code is nowhere near ready.

> So you *do* see
> a distinction between architectural changes that should wait until
> after G2 is released and those that are necessary now?  Could you
> explain what that distinction is?

1. QOF 0.6.0 is ready and I want to do what I can to allow gnucash to use it
fully.
2. cashutil is a recent addition and is not ready.
3. Undo is simply too large a feature to add in these circumstances. It is
still v.new and insufficiently tested.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Neil Williams-2
In reply to this post by Chris Shoemaker
On Sunday 02 October 2005 8:17 pm, Chris Shoemaker wrote:
> > I agree none of the QOF stuff is related to the GUI port to Gtk2 but it
> > is all related to the underlying port to glib-2.
> >
> > The original desire for a G2 port, in my understanding, was to port
> > gnucash to the gnome2 libraries, not just port the GUI to Gtk2.
>
> That's my understanding as well.  So, what functionality in glib1 is
> missing from glib2 that requires the QOF pullout?

Principally the backend load method. QSF also requires a recent libxml2 that
the 1.8 tree could not support which is why it was committed to G2 in the
first place.

> Is this a tree-sync
> issue? i.e.: external QOF has moved forward to version w/o glib1,
> therefore the easiest way to remove glib1 dep from gc is to upgrade
> internal qof to new version, which requires massive factoring?

All that work has already been done and copied into gnc. It is also in QOF and
I merely wish to not duplicate such large amounts of code.

G2 will work on glib-2 on those platforms that don't package QOF - I just want
to make sure it's possible to use QOF on those platforms that DO provide it.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Chris Shoemaker
In reply to this post by Neil Williams-2
On Sun, Oct 02, 2005 at 08:58:47PM +0100, Neil Williams wrote:

> On Sunday 02 October 2005 7:46 pm, Chris Shoemaker wrote:
> > > |         Now I understand any such policy is merely an ideal whose
> > > | actual application must also consider many practicalities.
> > >
> > > One of which is spinning out QOF.
> >
> > Care to explain that?  I was more thinking about practicalities such
> > as developer time and efficiency.
>
> 1. Removing scheme/guile from the engine code - an inherent task within
> spinning out QOF, two sides of the same coin.

Laudable, believe me.  But necessary for G2 release?

>
> 2. Not to put too fine a point on it, my developer time copying QOF files into
> GnuCash each time it needs an update!

Why does G2 always need newest QOF?

> Gnucash is benefitting from wider use
> of QOF and will benefit much, much more as cashutil develops. I know that
> probably doesn't matter to you but it does to me.
>
> 3. In terms of user experience and expectation in G2, QSF exports and QOF
> merge will provide solutions to real user problems relating to data import,
> export, mining and customised report generation.

All these are wonderful, but they are *new*features*.


> The GUI code to get the best
> out of QSF is not all in place but there is sufficient - particularly with
> the business features - to make it very useful. Adding similar commands to
> export accounts and transactions between specified dates into QSF is a small
> task - it depends on how other things pan out.
>
> If you limit it to an empty feature-parity then this last fix for the error
> logging and finishing the fix to the backend load method are the only
> remaining QOF tasks. The rest of the code is already in place and has been
> for some weeks.

This backend load method doesn't sound like a broad architectural
change.  Is it?  Does that mean you won't make any more such changes
until G2 is released?
 

> > > I get the same with all the GOffice code and it's dependencies. Then OSX
> > > has horrible problems with the frequent use of -module in the makefiles.
> >
> > You get massive patch breaking due to code churn?!?  What code has
> > been churning under you? Surely not GOG.
>
> The goffice code in the gnucash tree hasn't necessarily changed, but the
> dependencies of that code HAS changed, that's why I have several patches for
> files under lib/goffice to allow it to compile. I'll be looking at using
> external GOffice libraries soon - should have done it earlier but had to get
> QOF ready for pre-release.
>
> > > I wish you'd said something when I started talking about trace changes
> > > on this list. Are these changes compatible with using trace via the
> > > external QOF library?
> >
> > Some are.  Some aren't.
>
> So what are the benefits of your trace changes? What do they cover?

Easier addition of new logging modules - but your changes are more
extensive than mine.

>
> > There might be a logical leap here.
> >
> > 1) QOF needs release imminently.  [ Let's take this as a given. ]
> >
> > 2) GC needs to use QOF as external library.
> >     [ I'm not exactly sure how strong a need I would admit, but let's
> > assume this is completely true. ]
> >
> > 3) Therefore, GC needs, in the next G2 release, all these
> > architectural changes to support the new release of QOF.
> >
> > I don't see 3) following from 1) and 2), but feel free to make the
> > case.
>
> 1. GC needs the backend to be fixed. There is a working fix out-of-tree but it
> needs to be fitted into GC.

What's broken about current G2 backend?  I only use the xml backend,
so from my perspective it already works well enough in G2 to release.
Am I missing something?

> 2. I anticipate that remaining issues should be small and therefore it is
> worthwhile seeing if G2 can work with an external QOF once the backend is
> fixed. I see no point in releasing G2 with an internal QOF library that is
> maybe 99% identical to 0.6.0. I really do feel that once the backend is
> fixed, the remaining work is that small. This last patch achieved a massive
> amount of progress on separating QOF from gnucash. It could (should) have
> been done a long time ago.
>
> > Don't assume that everyone knows what you know about the wonderful
> > benefits of QOF.
>
> My motivation at the moment is simply to avoid duplicate code. Whenever
> possible, G2 should be allowed to use an external QOF library that will be
> available before G2 and which contains virtually identical code.

Ah, I think I'm starting to understand.  You want to allow G2 to use
external QOF.  Is there consensus that G2 shouldn't be released until
we've achieved this goal?  I'm asking because I'm fine with a G2
release that uses internal QOF.  In fact, if externalizing QOF is
delaying G2 release, I think that's bad.  What do others think?

>
> > Please explain why G2 can't be released, with
> > feature parity with "G1", without architectural improvements.
>
> The only remaining problem is that in the backend. I expect to be able to fix
> that in the next two weeks (I'm away most of next week). The current gnc-
> code is not working properly.
>
> There are also architectural changes to the makefiles for libraries that use
> -module for G2 to work on Mac OSX. Those warnings that we all see about
> linking executables against ... library not beng portable - those warnings
> bite on OSX and those were not a problem with the 1.8 tree (I think due to
> the version of gcc available for 1.8). They will, however, halt the build of
> any G2 package if not fixed.

Yeah, I think this is critical.  I wish my patch breakage were from
things like this being fixed.

>
> A relatively minor change that I need to be able to test and then implement.
>
> > Note
> > that it's not enough to simply explain how great QOF is for GC.  Lots
> > of things are great for GC that won't be in the first release of G2.
> > Why should all these QOF changes?
>
> 1. To make use of the gnome2 architecture at the level of glib.

But your changes aren't related to dropping a glib1 dep, right?

>
> 2. To prevent duplicate code - I will do everything I can to allow G2 to go
> into at least Debian with an external QOF dependency. I have completed the
> vast majority of that work, I only have a few fixes left to implement. After
> that, libqof1 will remain API compatible for some time so gnucash can make
> subsequent releases without problems or synchronisation. It's just that there
> have been so many changes from QOF 0.5 to QOF 0.6, it's all a little fraught
> at the moment.

Duplicate QOF is obviously not ideal, but if we worked on
externalizing all the in-tree libraries, G2 would never be released.
We have to draw a line somewhere.

>
> > > Then there are the changes required to work with cashutil - again these
> > > are architectural changes to libraries and makefiles, as well as the
> > > abstraction of the GUI logic into a library to be shared with cashutil.
> >
> > Again, fine, let's assume cashutil is wonderful.  Do we have to make
> > architectural changes to G2 to work with cashutil in order to achieve
> > feature parity?
>
> No. cashutil is completely separate, it has helped me fix the backend problem
> but it's main contribution won't be visible for a time after QOF 0.6 and G2.
> I could not have started cashutil without the work I've done already for QOF
> and the new pilot-QOF application.

So these are architectural changes that won't benefit us until far
down the road.  Those types of improvements are very important but I
think they shouldn't have been done in G2.  I hope you'll save these
types of changes for the next developement tree.

>
> > > I've got a usable undo framework out-of-tree and it will stay there for
> > > now. I'll also be implementing the logic abstraction out-of-tree. I
> > > can't introduce those to the gnucash tree until gnucash itself is closer
> > > to accepting cashutil which in turn requires a completed QOF spinout.
> >
> > [I'm assuming you're thinking post-G2 release here.]
>
> Yes, principally because cashutil requires large amounts of new or relocated
> code to implement the logic. That code is nowhere near ready.
>
> > So you *do* see
> > a distinction between architectural changes that should wait until
> > after G2 is released and those that are necessary now?  Could you
> > explain what that distinction is?
>
> 1. QOF 0.6.0 is ready and I want to do what I can to allow gnucash to use it
> fully.

You essentially mean "externally", right?  I'm skeptical of the
necessity for this in G2, but if you're saying there's not much more
to be done, I'll stop complaining.

-chris

> 2. cashutil is a recent addition and is not ready.
> 3. Undo is simply too large a feature to add in these circumstances. It is
> still v.new and insufficiently tested.
>
> --
>
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
>



> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about use of G2

Chris Shoemaker
In reply to this post by Neil Williams-2
On Sun, Oct 02, 2005 at 09:03:21PM +0100, Neil Williams wrote:

> On Sunday 02 October 2005 8:17 pm, Chris Shoemaker wrote:
> > > I agree none of the QOF stuff is related to the GUI port to Gtk2 but it
> > > is all related to the underlying port to glib-2.
> > >
> > > The original desire for a G2 port, in my understanding, was to port
> > > gnucash to the gnome2 libraries, not just port the GUI to Gtk2.
> >
> > That's my understanding as well.  So, what functionality in glib1 is
> > missing from glib2 that requires the QOF pullout?
>
> Principally the backend load method.

huh? in glib1?

> QSF also requires a recent libxml2 that
> the 1.8 tree could not support which is why it was committed to G2 in the
> first place.

Well, QSF requiring G2 doesn't mean the first G2 release requires QSF.

>
> > Is this a tree-sync
> > issue? i.e.: external QOF has moved forward to version w/o glib1,
> > therefore the easiest way to remove glib1 dep from gc is to upgrade
> > internal qof to new version, which requires massive factoring?
>
> All that work has already been done and copied into gnc. It is also in QOF and
> I merely wish to not duplicate such large amounts of code.
>
> G2 will work on glib-2 on those platforms that don't package QOF - I just want
> to make sure it's possible to use QOF on those platforms that DO provide it.

Wait a sec.  You mean GC G2 release has to work both ways!?  with
external QOF on Debian and with internal QOF on other dist?  If so,
then working with external QOF certainly shouldn't hold up G2.

-chris
>
> --
>
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
>



> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Mac OS X -module (was Re: Confusion about use of G2)

Peter O'Gorman
In reply to this post by Neil Williams-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Williams wrote:
| There are also architectural changes to the makefiles for libraries that use
| -module for G2 to work on Mac OSX. Those warnings that we all see about
| linking executables against ... library not beng portable - those warnings
| bite on OSX and those were not a problem with the 1.8 tree (I think due to
| the version of gcc available for 1.8). They will, however, halt the build of
| any G2 package if not fixed.
|

If you look at configure.in, you'll see a god awful hack to change the value
of archive_cmds on darwin after libtool is generated. I put the hack in
there in preference to changing lots and lots of Makefile.am's. If you want
to change the Makefiles so that the loadable module only contains the file
which has the gnc_module_init functions and it links to all shared library's
needed so that there are no undefined symbols anywhere (I believe this would
also greatly improve the chances of a working windows build), that will
solve the problem.

I suggest the short term hack of adding to the ugly sed hack in configure to
set libtool's "module_cmds" var to nothing. eg. -e
's,^module_cmds=.*,module_cmds=,g' or something, this will make the build
better on OS X. I don't understand how you aremanaging to build on OS X at
the moment though.

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ0Bs9biDAg3OZTLPAQIfnQP9FF8ZehAimSI/SUER3oG/kRj6FpQXpUrC
tb8UZABBE5ZHJoY1pQkAh/LFXwYNuUQXQRcs28x7Qmka0pKH6q0lsetMoJUAFMcb
aUPNsZoHbE3IBgwXJ+tETo4+TXmAIjXx8lpsFvxQoaYAZZzWct3XbxduUwhHx7XC
771iY3XB2Dg=
=sUn5
-----END PGP SIGNATURE-----
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Register rewrite [Was: Confusion about use of G2]

Didier Vidal
In reply to this post by Chris Shoemaker
[...]
>         Since then, I've also made substantial progress on a
> register-rewrite using the GtkTreeModel API.  It's been easier than I
> thought. (Although I've made no progress in the past 2 months - no
> time.)
>
Chris,

I'd be curious to see how this register implementation works.
There are still a couple of low-level bugs in the register-gnome
implementation I discovered recently:
   * You can't resize the gnucash window when a register is open
   * text selection doesn't work well if the text contains accented
chars
   * left-arrow + shift while attempting to select text creates unusual
behaviours
   * probable focus problem when using the account selection combo box
   * impractical text justification for account names (you see the
beginning of the name, not the end that most of the time is the relevant
part, if you have nested accounts).
   * missing tooltips for long strings

I your implementation is advanced enough, it might be worth considering
if it is not a faster path to a robust implementation of the register.

Didier.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X -module (was Re: Confusion about use of G2)

Peter O'Gorman
In reply to this post by Peter O'Gorman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter O'Gorman wrote:
| If you look at configure.in, you'll see a god awful hack to change the
| value
| of archive_cmds on darwin after libtool is generated. I put the hack in
| there in preference to changing lots and lots of Makefile.am's. If you want
| to change the Makefiles so that the loadable module only contains the file
| which has the gnc_module_init functions and it links to all shared
| library's
| needed so that there are no undefined symbols anywhere (I believe this
| would
| also greatly improve the chances of a working windows build), that will
| solve the problem.
|
| I suggest the short term hack of adding to the ugly sed hack in
| configure to
| set libtool's "module_cmds" var to nothing. eg. -e
| 's,^module_cmds=.*,module_cmds=,g' or something, this will make the build
| better on OS X. I don't understand how you aremanaging to build on OS X at
| the moment though.

Love replying to myself, do it all the time :)

I see that this mail is rather hard to follow (i.e. it makes no sense), so I
hope to make some sense of it, while attaching a patch. I don't post the
patch to -patches because a) I don't think I am subsribed to patches anymore
and b) these patches need discussion, one of them is a simple reversion of
one of Neil's.

First to libtool's warning about linking the loadable module foo crap. If,
for example. we have libgncmod-bar and it consists of file gncmodbar.c
reallycoolcode.c greatsharedcode.c and barstuff.c and we currently make just
one library that is both runtime loaded and linked then it needs, at some
point, to be changed to libgncmod-bar and libgncshared-bar with the code
that is only needed by the loadable module in the former, with the cool
shared code in the latter. The former can have the -module flag and the
latter not. This will then allow the ugly configure time libtool hack on
darwin to go away.

Now for the inline commented patch...
? bin
Index: configure.in
===================================================================
RCS file: /home/cvs/cvsroot/gnucash/configure.in,v
retrieving revision 1.359.2.64
diff -u -3 -p -u -r1.359.2.64 configure.in
- --- configure.in 1 Oct 2005 17:54:25 -0000 1.359.2.64
+++ configure.in 4 Oct 2005 15:48:09 -0000
@@ -159,9 +159,8 @@ AC_SUBST(DL_LIB)

~ # Some systems (MacOS) require -lintl
~ # not true for darwin 10.3 - halts the build.
- -#AC_SEARCH_LIBS(gettext, intl, ,[
- -# AC_MSG_ERROR([Cannot find gettext -- do you need to build -lintl?])], )
- -
+AC_SEARCH_LIBS(gettext, intl, ,[
+       AC_MSG_ERROR([Cannot find gettext -- do you need to build -lintl?])], )

I don't understand why you removed this, it causes no problems for me, and
once it fixed something...

~ AC_MSG_CHECKING(for darwin)
~ case $host_os in
~ rhapsody* | darwin1*)
@@ -170,28 +169,19 @@ case $host_os in
~ update to latest  darwin])
~ ;;
~ darwin*)
- -     dnl Use fink under MacOS X to find popt
- -     AC_MSG_CHECKING(for fink support)
- -     if test -d "/sw/lib" -a -d "/sw/include"; then
- -        AM_CFLAGS="$AM_CFLAGS -I/sw/include"
- -        LDFLAGS="$LDFLAGS -L/sw/lib"
- -        AC_MSG_RESULT(yes)
- -    else
- -        AC_MSG_RESULT(no)
- -    fi
- -    AC_CHECK_HEADERS(popt.h)


I have major issues with this. One is that /sw is simply the defauslt
install prefix for fink, it is not necessarily the one the user chose.
Another is that AC_CHECK_HEADERS takes no notice whatever of AM_CFLAGS, so
the whole thing is pointless. The user is expected to specify the location
of headers and libraries when they are installed in non-standard places with
CPPFLAGS and LDFLAGS.

~ AC_MSG_RESULT([yes, patching libtool to always build dylibs])
~ mv libtool libtool.old
~ sed -e 's/^deplibs_check_method.*/deplibs_check_method=pass_all/g' \
~ -e 's|^archive_cmds.*|archive_cmds="$CC -dynamiclib
\\$allow_undefined_flag -o \\$lib \\$libobjs \\$deplibs\\$linker_flags
- -install_name \\$rpath/\\$soname \\$verstring"|g' \
~ -e
's|^library_names_spec.*|library_names_spec="\\$libname\\$release\\$versuffix.dylib
\\$libname\\$release\\${major}.dylib \\$libname.dylib"|g' \
~ -e 's|^soname_spec.*|soname_spec="\\$libname\\$release\\$major.dylib"|g' \
+                       -e 's|^module_cmds=.*|module_cmds=|g' \

I don't understand how you've been building on Mac OS X, hampton kindly
removed some dupliacte symbol definitions for me yesterday which allowed my
build to finish. Resetting module_cmds to the empty string makes libtool use
the archive_cmds that we set above...

< libtool.old > libtool
~ rm libtool.old
- - ;;
+               ;;
~ *)
~ AC_MSG_RESULT(no)
- - ;;
+               ;;
~ esac


@@ -1001,14 +991,6 @@ then
~         fi
~     fi
~     AS_SCRUB_INCLUDE(GTKHTML_CFLAGS)
- -dnl if Mac OSX, also scrub /sw/include
- -dnl GIVEN_CFLAGS=$(echo $GIVEN_CFLAGS | sed -e "s;-I/sw/include ;;" | sed
- -e "s;-I/sw/include$;;")
- -case $host_os in
- - darwin*)
- - GTKHTML_CFLAGS=$(echo $GTKHTML_CFLAGS | sed -e "s;-I/sw/include ;;" | sed
- -e "s;-I/sw/include$;;")
- - GTKHTML_CFLAGS=$(echo $GTKHTML_CFLAGS | sed -e "s;-I/sw/include/gtkhtml
;;" | sed -e "s;-I/sw/includ/gtkhtmle$;;")
- - ;;
- -esac

Why are you scrubbing these, did you see an actual problem?


~     AC_SUBST(GTKHTML_CFLAGS)
~     AC_SUBST(GTKHTML_LIBS)

Index: lib/goffice/graph/plugins/plot_radar/gog-radar.c
===================================================================
RCS file:
/home/cvs/cvsroot/gnucash/lib/goffice/graph/plugins/plot_radar/Attic/gog-radar.c,v
retrieving revision 1.1.4.1
diff -u -3 -p -u -r1.1.4.1 gog-radar.c
- --- lib/goffice/graph/plugins/plot_radar/gog-radar.c 24 Apr 2005 00:34:53
- -0000 1.1.4.1
+++ lib/goffice/graph/plugins/plot_radar/gog-radar.c 4 Oct 2005 15:48:09 -0000
@@ -295,7 +295,7 @@ typedef GogPlotView GogRadarView;
~ typedef GogPlotViewClass GogRadarViewClass;

~ static double
- -fmin (double a, double b)
+gog_fmin (double a, double b)

I built using gcc-4.0 and --disable-error-on-warning and this was the only
place I saw an actual error. I've got a system fmin and gcc-4.0 complains
about static declaration after non-static. Since this is an actual error,
and even though I know this is an imported source, I'd appreciate this minor
change being made so that gcc-4.0 compilation is possible without patching.


~ {
~ return (a < b) ? a : b;
~ }
@@ -312,7 +312,7 @@ gog_radar_view_render (GogView *view, Go

~ map = gog_axis_map_new (GOG_PLOT (model)->axis[GOG_AXIS_RADIAL],
~ 0.,
- - fmin (view->allocation.h, view->allocation.w) / 2.0);
+ gog_fmin (view->allocation.h, view->allocation.w) / 2.0);

~ if (!gog_axis_map_is_valid (map)) {
~ gog_axis_map_free (map);
@@ -388,7 +388,7 @@ gog_radar_view_info_at_point (GogView *v
~      GogObject const *cur_selection,
~      GogObject **obj, char **name)
~ {
- - double radius = fmin (view->allocation.h, view->allocation.w)/2.0;
+ double radius = gog_fmin (view->allocation.h, view->allocation.w)/2.0;

~ x -= view->allocation.x + view->allocation.w/2.;
~ y -= view->allocation.y + view->allocation.h/2.;
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ0KsFbiDAg3OZTLPAQKzvgP8ConS44DXi3f0BgvM/NFj0AaJ6ClpIfld
Z3uH2yR6EAkSkC0FeZbs/j8SPy5orpEr0omwliTW7oVxbFtpP0iAPE8NI54w8Aek
HLlW7KYDTkguQFeU/4OET736UmxN2dHRGzaglNr/cUTEXt16+iL2jiz8Xf7zqKjW
ZWfdkA2AsPs=
=WiQi
-----END PGP SIGNATURE-----

? bin
Index: configure.in
===================================================================
RCS file: /home/cvs/cvsroot/gnucash/configure.in,v
retrieving revision 1.359.2.64
diff -u -3 -p -u -r1.359.2.64 configure.in
--- configure.in 1 Oct 2005 17:54:25 -0000 1.359.2.64
+++ configure.in 4 Oct 2005 15:48:09 -0000
@@ -159,9 +159,8 @@ AC_SUBST(DL_LIB)
 
 # Some systems (MacOS) require -lintl
 # not true for darwin 10.3 - halts the build.
-#AC_SEARCH_LIBS(gettext, intl, ,[
-# AC_MSG_ERROR([Cannot find gettext -- do you need to build -lintl?])], )
-
+AC_SEARCH_LIBS(gettext, intl, ,[
+       AC_MSG_ERROR([Cannot find gettext -- do you need to build -lintl?])], )
 AC_MSG_CHECKING(for darwin)
 case $host_os in
  rhapsody* | darwin1*)
@@ -170,28 +169,19 @@ case $host_os in
 update to latest  darwin])
  ;;
  darwin*)
-     dnl Use fink under MacOS X to find popt
-     AC_MSG_CHECKING(for fink support)
-     if test -d "/sw/lib" -a -d "/sw/include"; then
-        AM_CFLAGS="$AM_CFLAGS -I/sw/include"
-        LDFLAGS="$LDFLAGS -L/sw/lib"
-        AC_MSG_RESULT(yes)
-    else
-        AC_MSG_RESULT(no)
-    fi
-    AC_CHECK_HEADERS(popt.h)
  AC_MSG_RESULT([yes, patching libtool to always build dylibs])
  mv libtool libtool.old
  sed -e 's/^deplibs_check_method.*/deplibs_check_method=pass_all/g' \
  -e 's|^archive_cmds.*|archive_cmds="$CC -dynamiclib \\$allow_undefined_flag -o \\$lib \\$libobjs \\$deplibs\\$linker_flags -install_name \\$rpath/\\$soname \\$verstring"|g' \
  -e 's|^library_names_spec.*|library_names_spec="\\$libname\\$release\\$versuffix.dylib \\$libname\\$release\\${major}.dylib \\$libname.dylib"|g' \
  -e 's|^soname_spec.*|soname_spec="\\$libname\\$release\\$major.dylib"|g' \
+                       -e 's|^module_cmds=.*|module_cmds=|g' \
  < libtool.old > libtool
  rm libtool.old
- ;;
+               ;;
  *)
  AC_MSG_RESULT(no)
- ;;
+               ;;
 esac
 
 
@@ -1001,14 +991,6 @@ then
         fi
     fi
     AS_SCRUB_INCLUDE(GTKHTML_CFLAGS)
-dnl if Mac OSX, also scrub /sw/include
-dnl GIVEN_CFLAGS=$(echo $GIVEN_CFLAGS | sed -e "s;-I/sw/include ;;" | sed -e "s;-I/sw/include$;;")
-case $host_os in
- darwin*)
- GTKHTML_CFLAGS=$(echo $GTKHTML_CFLAGS | sed -e "s;-I/sw/include ;;" | sed -e "s;-I/sw/include$;;")
- GTKHTML_CFLAGS=$(echo $GTKHTML_CFLAGS | sed -e "s;-I/sw/include/gtkhtml ;;" | sed -e "s;-I/sw/includ/gtkhtmle$;;")
- ;;
-esac
     AC_SUBST(GTKHTML_CFLAGS)
     AC_SUBST(GTKHTML_LIBS)
 
Index: lib/goffice/graph/plugins/plot_radar/gog-radar.c
===================================================================
RCS file: /home/cvs/cvsroot/gnucash/lib/goffice/graph/plugins/plot_radar/Attic/gog-radar.c,v
retrieving revision 1.1.4.1
diff -u -3 -p -u -r1.1.4.1 gog-radar.c
--- lib/goffice/graph/plugins/plot_radar/gog-radar.c 24 Apr 2005 00:34:53 -0000 1.1.4.1
+++ lib/goffice/graph/plugins/plot_radar/gog-radar.c 4 Oct 2005 15:48:09 -0000
@@ -295,7 +295,7 @@ typedef GogPlotView GogRadarView;
 typedef GogPlotViewClass GogRadarViewClass;
 
 static double
-fmin (double a, double b)
+gog_fmin (double a, double b)
 {
  return (a < b) ? a : b;
 }
@@ -312,7 +312,7 @@ gog_radar_view_render (GogView *view, Go
 
  map = gog_axis_map_new (GOG_PLOT (model)->axis[GOG_AXIS_RADIAL],
  0.,
- fmin (view->allocation.h, view->allocation.w) / 2.0);
+ gog_fmin (view->allocation.h, view->allocation.w) / 2.0);
 
  if (!gog_axis_map_is_valid (map)) {
  gog_axis_map_free (map);
@@ -388,7 +388,7 @@ gog_radar_view_info_at_point (GogView *v
       GogObject const *cur_selection,
       GogObject **obj, char **name)
 {
- double radius = fmin (view->allocation.h, view->allocation.w)/2.0;
+ double radius = gog_fmin (view->allocation.h, view->allocation.w)/2.0;
 
  x -= view->allocation.x + view->allocation.w/2.;
  y -= view->allocation.y + view->allocation.h/2.;

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X -module (was Re: Confusion about use of G2)

David Hampton-2
On Wed, 2005-10-05 at 01:21 +0900, Peter O'Gorman wrote:

> ~ static double
> - -fmin (double a, double b)
> +gog_fmin (double a, double b)
>
> I built using gcc-4.0 and --disable-error-on-warning and this was the only
> place I saw an actual error. I've got a system fmin and gcc-4.0 complains
> about static declaration after non-static. Since this is an actual error,
> and even though I know this is an imported source, I'd appreciate this minor
> change being made so that gcc-4.0 compilation is possible without patching.

What's the definition for the system fmin() function?

David


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Register rewrite [Was: Confusion about use of G2]

Chris Shoemaker
In reply to this post by Didier Vidal
On Tue, Oct 04, 2005 at 09:12:21AM +0200, Didier Vidal wrote:

> [...]
> >         Since then, I've also made substantial progress on a
> > register-rewrite using the GtkTreeModel API.  It's been easier than I
> > thought. (Although I've made no progress in the past 2 months - no
> > time.)
> >
> Chris,
>
> I'd be curious to see how this register implementation works.
> There are still a couple of low-level bugs in the register-gnome
> implementation I discovered recently:
>    * You can't resize the gnucash window when a register is open
>    * text selection doesn't work well if the text contains accented
> chars
>    * left-arrow + shift while attempting to select text creates unusual
> behaviours
>    * probable focus problem when using the account selection combo box
>    * impractical text justification for account names (you see the
> beginning of the name, not the end that most of the time is the relevant
> part, if you have nested accounts).
>    * missing tooltips for long strings
>
> I your implementation is advanced enough, it might be worth considering
> if it is not a faster path to a robust implementation of the register.

Well, I don't know which way is faster.  I just know that a
register-rewrite is certainly required eventually.  

I figure I'll just keep working on it until it's ready.  If it's ready
before G2 then maybe it makes sense to put it into G2.  If you want to
help with register-rewrite, let me know.

I've been meaning to set up a website for my current progress, but
it's never been the most urgent thing.  If you think you might be
interested in helping, it would be more urgent.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X -module (was Re: Confusion about use of G2)

Peter O'Gorman
In reply to this post by David Hampton-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Hampton wrote:
| On Wed, 2005-10-05 at 01:21 +0900, Peter O'Gorman wrote:
|
|
|>~ static double
|>- -fmin (double a, double b)
|>+gog_fmin (double a, double b)

| What's the definition for the system fmin() function?

It is exactly the same, double fmin( double, double ); but I didn't feel
like makeing a configure time check....

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ0MmZbiDAg3OZTLPAQKjewQAieb476hDg4NQ1wynCzXH9NvM5o+GBDg0
TXZGEsLfUm9z8Wc135YRSx0uYxAH3aF/pKS4WEREVlVVwu74Bx4PT4UyBkwCDmu7
pv4OTAAgRefVY1vsTV5D+DvkuVwhi8OtG0xZNdo6zGRe2+8JCr7IjGBMKVLdMPnc
z4wpewpRUYQ=
=Ibvd
-----END PGP SIGNATURE-----
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X -module (was Re: Confusion about use of G2)

David Hampton-2
On Wed, 2005-10-05 at 10:03 +0900, Peter O'Gorman wrote:
> It is exactly the same, double fmin( double, double ); but I didn't feel
> like makeing a configure time check....

I was thinking more along the lines of an "#ifndef DARWIN" around the
goffice definition of fmin().  Is there some #define that's only set
during the mac build?

David


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
123