> On Feb 5, 2024, at 03:40, Kevin Buckley via gnucash-devel
> wrote:
>
> On Monday, February 5th, 2024 at 12:36, john wrote:
>>
>> Those XML changes sound like the wrong direction.
>> XML code needs to stay in libgnucash/backend, not get mixed in with
>> engine/QOF,
>> especially since the
t to minimize introducing bugs, but others have
>> > probably put more thought into how to handle this.
>> >
>> > So I'm looking for some direction either on what the end goal is and
>> how to
>> > achieve it, or direction to leave QIF alone for now
On Monday, February 5th, 2024 at 12:36, john wrote:
>
> Those XML changes sound like the wrong direction.
> XML code needs to stay in libgnucash/backend, not get mixed in with
> engine/QOF,
> especially since the long-range plan is to turn XML into a backup format
> with SQL being the primary st
cing bugs, but others have
>> > probably put more thought into how to handle this.
>> >
>> > So I'm looking for some direction either on what the end goal is and how to
>> > achieve it, or direction to leave QIF alone for now and work on some other
>> &
m looking for some direction either on what the end goal is and how
> to
> > achieve it, or direction to leave QIF alone for now and work on some
> other
> > area of the codebase (suggestions welcome).
> >
>
> Hi Brian,
>
> Welcome to GnuCash.
>
> Rewriting the QI
ome).
>
Hi Brian,
Welcome to GnuCash.
Rewriting the QIF importer to C++ is a reasonable task if that's what motivates
you. It's not on the roadmap in more than the most generic "get rid of Guile"
sense, but it does seem like a good project to take on. It's as good a le
I've been looking at the import code and documentation and I'm wondering
what the overall plan and path is. It looks like there is a "generic"
implementation in the top level directory which has utilities that are
being converted to C++. I can see the importers making some calls into
this. What
Sounds good to me, too. Thanks!
Christian
Geert Janssens schrieb:
>On Sunday 10 November 2013 14:07:45 John Ralls wrote:
>> With the translation updates and Patrick’s rather warmly received
>> patch for https://bugzilla.gnome.org/show_bug.cgi?id=336843
>> —whoever’s doing the Gnucash Google+ a
On Sunday 10 November 2013 14:07:45 John Ralls wrote:
> With the translation updates and Patrick’s rather warmly received
> patch for https://bugzilla.gnome.org/show_bug.cgi?id=336843
> —whoever’s doing the Gnucash Google+ account announced it to the
> world—I’m inclined to do another release later
On Nov 5, 2013, at 1:32 PM, Christian Stimming wrote:
> Am Dienstag, 5. November 2013, 19:52:05 schrieb Geert Janssens:
>> On Tuesday 05 November 2013 11:25:55 Geert Janssens wrote:
>>> I've run some tests. If I add the gsettings schemas to the
>>> translatable strings, well translated languages
Am Dienstag, 5. November 2013, 19:52:05 schrieb Geert Janssens:
> On Tuesday 05 November 2013 11:25:55 Geert Janssens wrote:
> > I've run some tests. If I add the gsettings schemas to the
> > translatable strings, well translated languages get between 50 and 70
> > new fuzzy or untranslated string
Il 05/11/2013 19.52, Geert Janssens ha scritto:
Now how do we get the translators in action ?
I know there is something with the translation project, but I have never
done anything in that area.
Perhaps Cristian or Christian can provide some insight here ?
Geert
I can only say that new po
On Tuesday 05 November 2013 11:25:55 Geert Janssens wrote:
>
> I've run some tests. If I add the gsettings schemas to the
> translatable strings, well translated languages get between 50 and 70
> new fuzzy or untranslated strings. It's less for languages for which
> translations are less complete
On Nov 5, 2013, at 6:44 AM, Robert Ratliff wrote:
> Out of curiosity, how is the documentation usually bundled with a new stable
> release into the pre-built binaries? Do you just use the latest revision from
> the gnucash-docs repository?
If you mean the Mac and Win32 bundles, yes.
Regards,
Out of curiosity, how is the documentation usually bundled with a new
stable release into the pre-built binaries? Do you just use the latest
revision from the gnucash-docs repository?
On 11/4/2013 3:34 PM, Geert Janssens wrote:
With 2.5.7 out of the door, I would like to look ahead at 2.6.
I
I seem to
> remember we should provide a tarball with up to date po files or
> something ? I'm even wondering if we shouldn't release a 2.5.8 right
> after the last strings are added and call that the base for translators
> ?
>
> > As long as there aren’t any ki
e translations in 2.5.x ? I seem to
remember we should provide a tarball with up to date po files or
something ? I'm even wondering if we shouldn't release a 2.5.8 right
after the last strings are added and call that the base for translators
?
> As long as there aren’t any killer bugs
From earlier conversations, the last plan was to release 2.6 by the end
> of the year. Is this realistic ?
>
We should wait for you to fix the strings.
As long as there aren’t any killer bugs, I think the December 3 release can
be RC1 and plan for 2.6 between Christmas and New Year’s Eve.
I’l
On Monday 04 November 2013 22:34:01 Geert Janssens wrote:
> With 2.5.7 out of the door, I would like to look ahead at 2.6.
>
> I have just gone through the open bugs targeting the 2.6 milestone and
> reduced the set from 21 to 14. Some of the bugs I removed were
> actually bugs against register2 w
With 2.5.7 out of the door, I would like to look ahead at 2.6.
I have just gone through the open bugs targeting the 2.6 milestone and
reduced the set from 21 to 14. Some of the bugs I removed were actually
bugs against register2 which is not a feature for 2.6 any more. Some
need more info befor
something unpleasant if
too many new things are in 2.6.x, and also we tend to forget about the new
features if their introducting was too long ago.
> > So here's a rough proposal of a roadmap:
> >
> > 2.6 (early 2012 ?)
> > - replace all deprecated library dependenci
t;as fast as
> possible": the removal of deprecated libraries. Gnome 3 has been released and
> I think our next major release should really be Gnome 3 compatible. This
> change will take a lot of work in itself already, but can be accomplished in
> a
> shorter timefram
change will take a lot of work in itself already, but can be accomplished in a
shorter timeframe than the full refactoring in my opinion.
So here's a rough proposal of a roadmap:
2.6 (early 2012 ?)
- replace all deprecated library dependencies
- full unit test coverage of all core libraries
-
I think there's a page on the Gnucash wiki with a summary.
Nick.
-Original Message-
From: Christian Doyle
Sent: 11/04/2011 14:34:58
To: Ryan M. Ward
Cc: gnucash-devel@gnucash.org
Subject: Re: Budget, cash flow and scheduled transactions - roadmap?
Does anyone have a link to
ties by getting the word out
> with each email I send, I encourage you to do the same.
>
>
>
>
> > From: silvercro_mag...@hotmail.com
> > To: gnucash-devel@gnucash.org
> > Subject: FW: Budget, cash flow and scheduled transactions - roadmap?
> > Date: Sun, 3 Apr
eduled transactions - roadmap?
> Date: Sun, 3 Apr 2011 08:02:18 +
>
>
> Dang it, hitting reply does not always post to the list.
>
> --
> Ryan M. Ward
>
> *Note: This email was sent from a computer running Ubuntu Linux 9.10 (Karmic
> Koala)
> http://www.ubunt
: Budget, cash flow and scheduled transactions - roadmap?
Date: Sun, 3 Apr 2011 08:01:17 +
enhancing the budgeting feature is a big priority for me as well, I have not
had the time lately to work on it myself but if a team were to form, I would
gladly join, time permitting.
--
Ryan M
Zitat von Nick Manville :
I would like a budgeting system that allows me to combine my
scheduled transactions, budget amounts and asset balances to allow
me to plan my future spending. This is for managing personal finance
rather than business accounting which has its own rules and language.
Hi,
I would like a budgeting system that allows me to combine my scheduled
transactions, budget amounts and asset balances to allow me to plan my future
spending. This is for managing personal finance rather than business accounting
which has its own rules and language.
The current budget does
On Sun, Mar 22, 2009 at 01:46:28PM -0700, Andrew Sackville-West wrote:
> On Sat, Mar 21, 2009 at 03:46:32PM -0400, Phil Longstaff wrote:
> > As far as I can tell, there are a number of things that are in trunk or are
> > being developed:
[...]
> > 5) changes to saved reports - Andrew Sackville-Wes
Am Samstag, 21. März 2009 20:46 schrieb Phil Longstaff:
> As far as I can tell, there are a number of things that are in trunk or are
> being developed:
>
> 1) libdbi backend - in trunk. I've been using it for a while now.
> 2) replace gtkhtml with webkit - I've just started on a branch
> 3) regis
On Sat, Mar 21, 2009 at 03:46:32PM -0400, Phil Longstaff wrote:
> As far as I can tell, there are a number of things that are in trunk or are
> being developed:
>
> 1) libdbi backend - in trunk. I've been using it for a while now.
> 2) replace gtkhtml with webkit - I've just started on a branch
On Sat, Mar 21, 2009 at 12:46 PM, Phil Longstaff wrote:
> As far as I can tell, there are a number of things that are in trunk or are
> being developed:
>
> 1) libdbi backend - in trunk. I've been using it for a while now.
> 2) replace gtkhtml with webkit - I've just started on a branch
> 3) regi
As far as I can tell, there are a number of things that are in trunk or are
being developed:
1) libdbi backend - in trunk. I've been using it for a while now.
2) replace gtkhtml with webkit - I've just started on a branch
3) register rewrite - Charles Day has done a lot of work fixing up the
re
On Thu, Jan 11, 2001 at 10:56:59PM -0500, David Merrill wrote:
> Would someone be so kind as to point me in the direction of what the
> release/feature plans are for the next release of gnucash? Can we
> talk about the long range plans for the database? Hey, I'm the
> newcomer here, and I'd like t
Would someone be so kind as to point me in the direction of what the
release/feature plans are for the next release of gnucash? Can we talk
about the long range plans for the database? Hey, I'm the newcomer
here, and I'd like to know what you have all been planning.
tia,
David
--
Dr. David C.
It's been rumoured that Jeremy Collins said:
>
> Perhaps we could work out a RoadMap for development. Something along these
> lines:
>
> Version 1.2
> - Motif GUI
> - Reports via Perl/SWIG
> - *ANY OTHER CURRENTLY IMPLEMENTED FEATURES HERE*
>
> Ver
Jeremy Collins <[EMAIL PROTECTED]> writes:
> Basically I think we should do as Rob said and freeze the current
> source tree. This way we can focus on releasing a stable version
> based on Motif. I would be willing to hammer on the Motif code.
s/freeze/branch/, and I'd agree. I think CVS is p
Just to throw more ideas around...
Perhaps we could work out a RoadMap for development. Something along these
lines:
Version 1.2
- Motif GUI
- Reports via Perl/SWIG
- *ANY OTHER CURRENTLY IMPLEMENTED FEATURES HERE*
Version 2.0
- Gtk/Gnome GUI ( Motif dropped )
- Reports via Guile
39 matches
Mail list logo
