es to the point that I can manage it, but I will only
have time and ability for smaller patches for the time being.
Thanks,
-Tim M
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Hello,
Per my previous email I am looking at compiler warnings/errors and I
found an interesting one for which I could use some advice. During
make, libqof came up with a fairly large number of errors, including
quite a few "comma at end of enumerator list" errors. Some of the
errors were quite
On Mon, Jun 6, 2011 at 9:02 AM, Derek Atkins wrote:
> Christian Stimming writes:
>
>> But in general: I don't see the value of those macros here anyway. I
>> mean, the list of enum values need to appear in the definition of
>> LOG_LEVEL_LIST anyway. Passing this list through two other macros
>>
SO C89, as long as it doesn't make the code less
> readable. We are looking forward to seeing your patches!
>
I will avoid the --enable-iso-c option.
Cheers,
-Tim M
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Since all roads lead to nowhere, I will just leave it alone.
Next time I have time, I'll disable iso-c and see if I can find more
important issues to address :)
Thanks,
-Tim
On Tue, Jun 7, 2011 at 12:16 PM, Derek Atkins wrote:
> Jim Paris writes:
>
>> DEFINE_ENUM can just add a dummy element t
At the moment it appears that bugzilla is down or under maintenance as
I can access the defects but it is timing out when I try to commit
comments. So for reference I will post to the ML until bugzilla is
back up and then add my comments to the appropriate defects.
For bug #583520,
https://bugzil
I haven't been around here long, but I'll throw in a couple thoughts
since there hasn't been much commentary:
First, I like the mission statement as Geert suggested and is
currently written on the Charter page. It isn't too long or too
short, I think if you start discussing all of the goals (comm
ch that it was going to be validating against a 30-year old
standard! It was my mistake.
Thanks,
-Tim
On Fri, Jun 10, 2011 at 8:28 AM, Geert Janssens
wrote:
> On woensdag 8 juni 2011, Tim M wrote:
>
>> Since all roads lead to nowhere, I will just leave it alone.
>
>>
&
It seems as though NextSprocket has few active users or (realistic) tasks
available. Most existing tasks are posted by the user 'roger pack' and most
of his posted requests seem bogus IMO. The site is an interesting idea, but
I can't see why any serious developer would spend any significant amoun
Hi,
As you know I have done a little work on the reporting system to try to get
some form of standards-compliance working. I have been looking through
previous mails back to January to see what other activity there has been on
the reporting system, and found some work being done to use jqplot for
On Thu, Jul 7, 2011 at 9:25 AM, John Ralls wrote:
>
> Christian: Please don't accept Python code into Gnucash. Python has
> version-to-version compatibility problems, and I've found with pure-python
> applications like Gramps that it requires bundling a Python interpreter with
> the application s
What I'm looking for is this:
Separate the act of actually gathering the data from the GnuCash database
from transforming it for display, so that the output can be made much more
interactive and easy to style and make 'pretty' :). Use a well known
programming language to aggregate the data to mak
Yawar's suggestion is quite interesting, but the declarative XML you suggest
is bordering the functionality of a web service. I like the idea of having
the XML declarations but there still then must be some way for the user to
select individual accounts included in the report, which will require s
On Fri, Jul 8, 2011 at 8:44 AM, John Ralls wrote:
>
> This is in general a good plan, but you need to know that there's a reason
> for the engine code to be between the storage backends and the GUI and
> reporting system: It's the part that knows how to manage currencies and lots
> and invoices a
On Fri, Jul 8, 2011 at 10:28 AM, John Ralls wrote:
>
> I think it could be implemented as just another interface to the data such
> as we have XML and DBI currently
>
> Those are the database or storage layer interfaces that engine uses for
> persistence, not interfaces that presentation layer co
Agreed. That sounds like a good plan.
-Tim
On Fri, Jul 8, 2011 at 4:54 PM, John Ralls wrote:
>
> On Jul 8, 2011, at 1:25 PM, Tim M wrote:
>
> On Fri, Jul 8, 2011 at 10:28 AM, John Ralls wrote:
>
>>
>> I think it could be implemented as just another interface to the
XHTML 1.0 and HTML 4.01 Strict are nearly identical. Personally I like some
of the XHTML code styles betters (such as instead of ) so I
would shoot for that, but I would start off trying to get it to validate
against HTML 4.01 Transitional first.
On Fri, Jul 29, 2011 at 3:27 PM, Derek Atkins wr
asset accounts (bank,
checking) so I'm not sure if it might cause problems with different account
types.
Please take a look and let me know how I can further improve it!
Thanks,
-Tim M.
Index: src/register/ledger-core/split-register-model.c
==
Hi guys,
I wrote a (beta) patch to display the running register balance in "View
Subaccounts" register view, which I submitted to the mailing list on July
10th. The original thread is here:
https://lists.gnucash.org/pipermail/gnucash-devel/2009-July/025807.html
(I don't have the original post i
ng out just where to put such a function and how to get
it working. I did try!
Also, this is my first FOSS patch, so let me know if there is anything I can
do differently or improve on, thanks!
-Tim M.
On Fri, Jul 10, 2009 at 10:53 AM, Tim M wrote:
> Hello,
>
> I've attached a B
.
3. Added the get_trans_total_amount_subaccounts() function which returns the
total amount of a transaction for the register's parent account and all
subaccounts.
On Fri, Sep 4, 2009 at 12:01 AM, Tim M wrote:
> OK, IMO the updated patch attached to this mail is ready for testing. This
>
NERAL_LEDGER if the ld->type == LD_SUBACCOUNTS.
-Tim
On Sun, Sep 6, 2009 at 6:58 PM, Tim M wrote:
> Attached is an update to the RC1 patch
>
> This patch improves the original "RC1" patch in the following ways:
> 1. reg_run_balance_RC2.dif
The attached patch is an enhancement to the original reg_run_balance patch
that was implemented. This patch has been created off of a recent trunk (in
the last week). It makes the following changes:
1. Add a gboolean to the argument list of the gnc_split_register_get_rbaln()
function. If the ne
I noticed yesterday a bug in the reg run balance patch that was applied,
there is now a "Balance" column displayed in the template transaction
register. If you open the scheduled transaction editor, then open a
scheduled transaction and go to the "Template Transaction" tab, there is a
"Balance" co
I should note that when testing this patch, I also tried setting the
RATE_CELL to column 7 for the template register (8 for non-template) and
leaving column 8 blank, but I was told that the RATE_CELL needs to be the
last column. When I tested a build with the RATE cell in col 7 for the
template re
FYI, the 2.3.6 news article on the front page says "GnuCash 2.3.9 released"
:)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
my mistake.
On 9/30/09, Derek Atkins wrote:
> Hi,
>
> Tim M writes:
>
>> I should note that when testing this patch, I also tried setting the
>> RATE_CELL
>> to column 7 for the template register (8 for non-template) and leaving
>> column
>> 8 blank, but I was
> >>
> >> It was ok before I picked up the last few days of changes.
> >> I am on Ubuntu 9.04.
> >>
> >> Is this something specific to me?
> >>
> >> It is late so I have not looked at the files indicated yet.
> >
> > This is very odd.. What version of slib do you have? What happens if
> > you do
template.
-Tim
2009/9/28 Christian Stimming :
> Am Samstag, 26. September 2009 14:59 schrieb Tim M:
>> I noticed yesterday a bug in the reg run balance patch that was applied,
>> there is now a "Balance" column displayed in the template transaction
>> register. If you
AM, Derek Atkins wrote:
> I'm pretty sure the blank column shouldn't be there... But I'm not sure
> what you're seeing.
>
> -derek
>
> Tim M writes:
>
>> Hmm was this a bug in 2.2.6? I've been using it as a benchmark (ubuntu
>> 9.04 isn
time. Here:
https://lists.gnucash.org/pipermail/gnucash-devel/2009-September/026438.html
And thanks for all the help!
On 10/2/09, Derek Atkins wrote:
> Tim M writes:
>
>> See the attached screenshot. It shows the far right of a template
>> transaction in GnuCash 2.2.6, w
ian
>
> Am Donnerstag, 1. Oktober 2009 04:23 schrieb Tim M:
>> The attached patch is an improvement to the original patch (and should
>> be applied over it, this patch was generated from very recent trunk
>> with the original patch already applied) which supplies the
able releases should be used for
testing purposes only.
"
My 2 cents,
-Tim M
On Wed, Nov 11, 2009 at 9:05 AM, Geert Janssens
wrote:
> On Wednesday 11 November 2009, Colin Law wrote:
> > 2009/11/11 Geert Janssens :
> > > Hi,
> > >
> > > There have been a
Geert, I do see what you are saying about the links.
However, to be honest I don't think the download links should be bypassing
the download screen of Sourceforge anyway, especially for the binaries and
source code. The HTML Readme is a tiny file on the other hand, so IMO it's
not a big deal if i
34 matches
Mail list logo
