FYI, I last compiled and successfully used GC on RHEL3 clone (Fermi
Scientific Linux 3.0.2). Since then I had upgraded in place to SL 4.0 (RHEL4
clone). It seems to be working.
Then I installed SL 4.0 fresh on a new system. GC RPM's wouldn't install. I
found I had to pull the gdk-pixbuf-gnome
In gnucash g2, you can sort accounts according to many criteria (name,
description, value). That looks cool, but there is a problem: if you try
to sort by 'type', you have
Asset
Equity
Expenses
Income
Liability
(that's in english, in french, the order is different, but no more
logical)
In Gnucash
Le dim 25/09/2005 à 22:53, Derek Atkins a écrit :
> Quoting Didier Vidal <[EMAIL PROTECTED]>:
>
> [snip]
>
> Good to hear the tests worked. That bodes well.
>
> > But maybe one could add a unit test in gnucash that opens a gnucash file
> > with non ascii parameters, and checks that the objects
Quoting Didier Vidal <[EMAIL PROTECTED]>:
[snip]
Good to hear the tests worked. That bodes well.
But maybe one could add a unit test in gnucash that opens a gnucash file
with non ascii parameters, and checks that the objects are built
properly. The test could even save the file and read it ag
Le dim 25/09/2005 à 22:20, Derek Atkins a écrit :
> Didier Vidal <[EMAIL PROTECTED]> writes:
>
> > Even with 2.6.16 of libxml, there is no *visible* problem as long as you
> > keep opening your file with libxml.
>
> Oh? So if you save it with gnucash + libxml2-2.6.16 and then open
> it with gnuc
Didier Vidal <[EMAIL PROTECTED]> writes:
> Even with 2.6.16 of libxml, there is no *visible* problem as long as you
> keep opening your file with libxml.
Oh? So if you save it with gnucash + libxml2-2.6.16 and then open
it with gnucash + libxml2-2.2.x, it will do the right thing? Even if
we har
I'm looking again at gnc-trace because I want to make it less GnuCash
specific.
I feel we need to let any QOF application create their own traces with their
own list of modules and not force MOD_GUI, MOD_LOT, MOD_ACCOUNT,
MOD_SX and others onto other applications.
In cashutil, I've been using
Le dim 25/09/2005 à 19:08, Didier Vidal a écrit :
> First, I apologize for an error I made in parent email. The libxml
> version I tested that fixed the problem is 2.6.22. It didn't require any
> change in the gnucash code (ie: still using xmlNodeDump)
I meant xmlElemDump
Didier.
First, I apologize for an error I made in parent email. The libxml
version I tested that fixed the problem is 2.6.22. It didn't require any
change in the gnucash code (ie: still using xmlNodeDump)
The actual bug report in libxml is
http://bugzilla.gnome.org/show_bug.cgi?id=159547
Daniel Veillard
On Sunday 25 September 2005 4:40 pm, Didier Vidal wrote:
> gnucash looks fine with utf-8. Neil's suggestion to write the encoding
> in write_v2_header in io-gncxml-v2.c makes a lot of sense.
(I wish my other code problems were so easy to solve!)
> The error I observed ("é" written with an ISO-885
Le dim 25/09/2005 à 18:03, Derek Atkins a écrit :
> Quoting David Hampton <[EMAIL PROTECTED]>:
>
> > On Sun, 2005-09-25 at 17:40 +0200, Didier Vidal wrote:
> >
> >> >From my tests, with a correct libxml realease, gnucash writes in utf-8
> >> whatever the current locale is.
> >>
> >> So, there is n
Quoting David Hampton <[EMAIL PROTECTED]>:
On Sun, 2005-09-25 at 17:40 +0200, Didier Vidal wrote:
>From my tests, with a correct libxml realease, gnucash writes in utf-8
whatever the current locale is.
So, there is no encoding problem.
Hallelujah!
Except for the fact that FC3 ships 2.6.16
On Sun, 2005-09-25 at 17:40 +0200, Didier Vidal wrote:
> >From my tests, with a correct libxml realease, gnucash writes in utf-8
> whatever the current locale is.
>
> So, there is no encoding problem.
Hallelujah!
David
___
gnucash-devel mailing list
Finally,
gnucash looks fine with utf-8. Neil's suggestion to write the encoding
in write_v2_header in io-gncxml-v2.c makes a lot of sense.
The error I observed ("é" written with an ISO-8859-1 encoding) was due
to a bug in libxml. I had libxml 2.6.16 on my machine.
I downloaded libxml 2.6.20 and
Le dim 25/09/2005 à 11:55, Neil Williams a écrit :
[...]
> >* The code pointed by Neil
> > (fprintf(out, "\n"); in io-gncxml-v2.c)
> > is not called when you save a gnucash file.
>
> ??? Umm, it is:
You are right, Neil. It is called. I did an error in my test.
Now, I know where to search from,
Le dim 25/09/2005 à 11:55, Neil Williams a écrit :
> On Sunday 25 September 2005 9:59 am, Didier Vidal wrote:
> > So, here is what I understand of the situation with encoding:
> >
> >* internally, gnucash-g2 data are in utf-8, whatever the locale used
> > to launch gnucash.
>
> True.
>
> > Wh
>
> > What lead me to believe this is a trace I added in
> > xaccAccountSetName, in src/engine/Account.c
>
[...]
> >
> > void
> > xaccAccountSetName (Account *acc, const char *str)
> > {
> >char * tmp;
> >
> >
> >printf("xaccAccountSetName: %s\n", str);
>
> ? The actual source
On Sunday 25 September 2005 9:59 am, Didier Vidal wrote:
> So, here is what I understand of the situation with encoding:
>
>* internally, gnucash-g2 data are in utf-8, whatever the locale used
> to launch gnucash.
True.
> What lead me to believe this is a trace I added in
> xaccAccountSetNam
So, here is what I understand of the situation with encoding:
* internally, gnucash-g2 data are in utf-8, whatever the locale used
to launch gnucash. What lead me to believe this is a trace I added in
xaccAccountSetName, in src/engine/Account.c
void
xaccAccountSetName (Account *acc,
19 matches
Mail list logo
