RFC - SX Projection Report ; Patch - SX enable/disable

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

RFC - SX Projection Report ; Patch - SX enable/disable

Peter McAlpine-2
Hello,

I have found GnuCash to be a very useful tool for tracking my  
personal finances (THANK YOU!), but as others have brought up  
previously (http://wiki.gnucash.org/wiki/Budgets) there has  
historically been mixed success implementing a budgeting feature.

I should be clear right now that it's not my intention to attack the  
work that has gone into the budgeting features that exist in GnuCash  
now, nor do I want to start a large thread about long term plans for  
budgets in GnuCash. I have experimented with the recently added  
budgeting feature and am unable to have it meet my personal needs.  
After some thought I came up with an idea for a feature which would  
present me with the information I need in a way that I (as a  
accounting novice) can easily understand. I have started working on  
this feature already but was encouraged by Josh to post to the -devel  
list before I get too far (and thus this email).

My proposal is merely this: to add an "SX Projection Report"
Input:
Any subset of a SX's
Any subset of accounts
A starting date (present time or earlier)
A finish date (any time after the starting date)

Output:
A [read-only] report (formatted similarly to the register) which  
would show what the selected account(s) would look like if the  
selected SX(s) were applied to them from the start date to the finish.

Example Usage Scenario:
The user wants to see if she can afford a new car that has payments  
of $500/month, the user will input their regular SX's and add one  
more [disabled (see below)] SX for the $500/month car payments. The  
user could then generate the SX Projection Report and see the impact  
on her accounts out to some arbitrary date.

It's my hope that this feature would meet mine (and hopefully  
other's) budgeting needs in a way that would not commit GnuCash  
development to any particular budgeting philosophy or development  
track. If users aren't interested in the way the report does  
budgeting they can easily just ignore the report altogether.

In order to get up to speed on the GnuCash source, I have taken the  
time to implement (the diff is attached) a feature which would be  
helpful when using this report: the ability to disable/enable SX's.

Motivation:
I need to input SX's to select when I run SX Projection Reports,  but  
I may not actually want these SX's to show up on the SLR dialog yet.

Implementation:
I have added an "Enabled" checkbox to the SX Editor dialog (all SX's  
default to being enabled). If the SX is disabled it does not get  
picked up when the SLR runs. The disabled SX's are (will be)  
available when selecting SX's for SX Projection Reports.

I look forward to hearing your feedback regarding the patch and  
feature proposal.

Thanks,
-Peter


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

sx-projection-r15477.diff (22K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC - SX Projection Report ; Patch - SX enable/disable

Tim Wunder (Lists)
On Tuesday 30 January 2007 10:23:48 pm Peter McAlpine wrote:

> Hello,
>
> I have found GnuCash to be a very useful tool for tracking my
> personal finances (THANK YOU!), but as others have brought up
> previously (http://wiki.gnucash.org/wiki/Budgets) there has
> historically been mixed success implementing a budgeting feature.
>
> I should be clear right now that it's not my intention to attack the
> work that has gone into the budgeting features that exist in GnuCash
> now, nor do I want to start a large thread about long term plans for
> budgets in GnuCash. I have experimented with the recently added
> budgeting feature and am unable to have it meet my personal needs.
> After some thought I came up with an idea for a feature which would
> present me with the information I need in a way that I (as a
> accounting novice) can easily understand. I have started working on
> this feature already but was encouraged by Josh to post to the -devel
> list before I get too far (and thus this email).
>
> My proposal is merely this: to add an "SX Projection Report"
> Input:
> Any subset of a SX's
> Any subset of accounts
> A starting date (present time or earlier)
> A finish date (any time after the starting date)
>
> Output:
> A [read-only] report (formatted similarly to the register) which
> would show what the selected account(s) would look like if the
> selected SX(s) were applied to them from the start date to the finish.
>
> Example Usage Scenario:
> The user wants to see if she can afford a new car that has payments
> of $500/month, the user will input their regular SX's and add one
> more [disabled (see below)] SX for the $500/month car payments. The
> user could then generate the SX Projection Report and see the impact
> on her accounts out to some arbitrary date.
>
> It's my hope that this feature would meet mine (and hopefully
> other's) budgeting needs in a way that would not commit GnuCash
> development to any particular budgeting philosophy or development
> track. If users aren't interested in the way the report does
> budgeting they can easily just ignore the report altogether.
>
> In order to get up to speed on the GnuCash source, I have taken the
> time to implement (the diff is attached) a feature which would be
> helpful when using this report: the ability to disable/enable SX's.
>
> Motivation:
> I need to input SX's to select when I run SX Projection Reports,  but
> I may not actually want these SX's to show up on the SLR dialog yet.
>
> Implementation:
> I have added an "Enabled" checkbox to the SX Editor dialog (all SX's
> default to being enabled). If the SX is disabled it does not get
> picked up when the SLR runs. The disabled SX's are (will be)
> available when selecting SX's for SX Projection Reports.
>
> I look forward to hearing your feedback regarding the patch and
> feature proposal.
>
Sounds interesting. But what about SX's that have variables? How would those
be handled by the report?

Regards,
Tim

--
Fedora Core release 5 (Bordeaux), Linux 2.6.18-1.2257.fc5
 23:10:01 up 15:50,  4 users,  load average: 0.17, 0.19, 0.26
MP3/OGG archive Total playlength : 9 days, 11 hours, 29 mins 56 seconds
"It's what you learn after you know it all that counts" John Wooden

_______________________________________________
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: RFC - SX Projection Report ; Patch - SX enable/disable

Peter McAlpine-2
My intention is to let the existing SX infrastructure do as much of  
the work as possible. As such I would simply let it handle the  
variables in SX's as the SLR would usually handle them.

-Peter

On 30-Jan-07, at 11:13 PM, Tim Wunder wrote:

> On Tuesday 30 January 2007 10:23:48 pm Peter McAlpine wrote:
>> Hello,
>>
>> I have found GnuCash to be a very useful tool for tracking my
>> personal finances (THANK YOU!), but as others have brought up
>> previously (http://wiki.gnucash.org/wiki/Budgets) there has
>> historically been mixed success implementing a budgeting feature.
>>
>> I should be clear right now that it's not my intention to attack the
>> work that has gone into the budgeting features that exist in GnuCash
>> now, nor do I want to start a large thread about long term plans for
>> budgets in GnuCash. I have experimented with the recently added
>> budgeting feature and am unable to have it meet my personal needs.
>> After some thought I came up with an idea for a feature which would
>> present me with the information I need in a way that I (as a
>> accounting novice) can easily understand. I have started working on
>> this feature already but was encouraged by Josh to post to the -devel
>> list before I get too far (and thus this email).
>>
>> My proposal is merely this: to add an "SX Projection Report"
>> Input:
>> Any subset of a SX's
>> Any subset of accounts
>> A starting date (present time or earlier)
>> A finish date (any time after the starting date)
>>
>> Output:
>> A [read-only] report (formatted similarly to the register) which
>> would show what the selected account(s) would look like if the
>> selected SX(s) were applied to them from the start date to the  
>> finish.
>>
>> Example Usage Scenario:
>> The user wants to see if she can afford a new car that has payments
>> of $500/month, the user will input their regular SX's and add one
>> more [disabled (see below)] SX for the $500/month car payments. The
>> user could then generate the SX Projection Report and see the impact
>> on her accounts out to some arbitrary date.
>>
>> It's my hope that this feature would meet mine (and hopefully
>> other's) budgeting needs in a way that would not commit GnuCash
>> development to any particular budgeting philosophy or development
>> track. If users aren't interested in the way the report does
>> budgeting they can easily just ignore the report altogether.
>>
>> In order to get up to speed on the GnuCash source, I have taken the
>> time to implement (the diff is attached) a feature which would be
>> helpful when using this report: the ability to disable/enable SX's.
>>
>> Motivation:
>> I need to input SX's to select when I run SX Projection Reports,  but
>> I may not actually want these SX's to show up on the SLR dialog yet.
>>
>> Implementation:
>> I have added an "Enabled" checkbox to the SX Editor dialog (all SX's
>> default to being enabled). If the SX is disabled it does not get
>> picked up when the SLR runs. The disabled SX's are (will be)
>> available when selecting SX's for SX Projection Reports.
>>
>> I look forward to hearing your feedback regarding the patch and
>> feature proposal.
>>
>
> Sounds interesting. But what about SX's that have variables? How  
> would those
> be handled by the report?
>
> Regards,
> Tim
>
> --
> Fedora Core release 5 (Bordeaux), Linux 2.6.18-1.2257.fc5
>  23:10:01 up 15:50,  4 users,  load average: 0.17, 0.19, 0.26
> MP3/OGG archive Total playlength : 9 days, 11 hours, 29 mins 56  
> seconds
> "It's what you learn after you know it all that counts" John Wooden
> _______________________________________________
> 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: RFC - SX Projection Report ; Patch - SX enable/disable

Tim Wunder (Lists)
Well, that sounds OK, but I'm not sure it would work for my usage pattern. I
have about 15-20 SX's per month with variables. In order to use the report,
that would seem to require a lot of data entry :(

Perhaps adding the ability to assign an estimated amount in the SX editor
would make using variables easier for the report. In other words, when a
variable is used on a SX entry, also allow the user to estimate what that
amount is.

Alternatively, have an "Estimate" flag on each entry to indicate that the
amount entered is an estimate and the amount should be treated as a variable.
(I believe that this is the way kmymoney handles variable amounts.)

Formula can just be formula., I would think...

I thought I had an RFE in bugzilla for something like that, but I can't seem
to find it :(

Tim

On Tuesday 30 January 2007 11:42:15 pm Peter McAlpine wrote:

> My intention is to let the existing SX infrastructure do as much of
> the work as possible. As such I would simply let it handle the
> variables in SX's as the SLR would usually handle them.
>
> -Peter
>
> On 30-Jan-07, at 11:13 PM, Tim Wunder wrote:
> > On Tuesday 30 January 2007 10:23:48 pm Peter McAlpine wrote:
> >> Hello,
> >>
> >> I have found GnuCash to be a very useful tool for tracking my
> >> personal finances (THANK YOU!), but as others have brought up
> >> previously (http://wiki.gnucash.org/wiki/Budgets) there has
> >> historically been mixed success implementing a budgeting feature.
> >>
> >> I should be clear right now that it's not my intention to attack the
> >> work that has gone into the budgeting features that exist in GnuCash
> >> now, nor do I want to start a large thread about long term plans for
> >> budgets in GnuCash. I have experimented with the recently added
> >> budgeting feature and am unable to have it meet my personal needs.
> >> After some thought I came up with an idea for a feature which would
> >> present me with the information I need in a way that I (as a
> >> accounting novice) can easily understand. I have started working on
> >> this feature already but was encouraged by Josh to post to the -devel
> >> list before I get too far (and thus this email).
> >>
> >> My proposal is merely this: to add an "SX Projection Report"
> >> Input:
> >> Any subset of a SX's
> >> Any subset of accounts
> >> A starting date (present time or earlier)
> >> A finish date (any time after the starting date)
> >>
> >> Output:
> >> A [read-only] report (formatted similarly to the register) which
> >> would show what the selected account(s) would look like if the
> >> selected SX(s) were applied to them from the start date to the
> >> finish.
> >>
> >> Example Usage Scenario:
> >> The user wants to see if she can afford a new car that has payments
> >> of $500/month, the user will input their regular SX's and add one
> >> more [disabled (see below)] SX for the $500/month car payments. The
> >> user could then generate the SX Projection Report and see the impact
> >> on her accounts out to some arbitrary date.
> >>
> >> It's my hope that this feature would meet mine (and hopefully
> >> other's) budgeting needs in a way that would not commit GnuCash
> >> development to any particular budgeting philosophy or development
> >> track. If users aren't interested in the way the report does
> >> budgeting they can easily just ignore the report altogether.
> >>
> >> In order to get up to speed on the GnuCash source, I have taken the
> >> time to implement (the diff is attached) a feature which would be
> >> helpful when using this report: the ability to disable/enable SX's.
> >>
> >> Motivation:
> >> I need to input SX's to select when I run SX Projection Reports,  but
> >> I may not actually want these SX's to show up on the SLR dialog yet.
> >>
> >> Implementation:
> >> I have added an "Enabled" checkbox to the SX Editor dialog (all SX's
> >> default to being enabled). If the SX is disabled it does not get
> >> picked up when the SLR runs. The disabled SX's are (will be)
> >> available when selecting SX's for SX Projection Reports.
> >>
> >> I look forward to hearing your feedback regarding the patch and
> >> feature proposal.
> >
> > Sounds interesting. But what about SX's that have variables? How
> > would those
> > be handled by the report?
> >
> > Regards,
> > Tim
> >
> > --
> > Fedora Core release 5 (Bordeaux), Linux 2.6.18-1.2257.fc5
> >  23:10:01 up 15:50,  4 users,  load average: 0.17, 0.19, 0.26
> > MP3/OGG archive Total playlength : 9 days, 11 hours, 29 mins 56
> > seconds
> > "It's what you learn after you know it all that counts" John Wooden
> > _______________________________________________
> > 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


--
Fedora Core release 5 (Bordeaux), Linux 2.6.18-1.2257.fc5
 10:00:01 up 1 day,  2:40,  4 users,  load average: 0.71, 0.48, 0.33
MP3/OGG archive Total playlength : 9 days, 11 hours, 29 mins 56 seconds
"It's what you learn after you know it all that counts" John Wooden

_______________________________________________
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: RFC - SX Projection Report ; Patch - SX enable/disable

Josh Sled
In reply to this post by Peter McAlpine-2
On Tue, 2007-01-30 at 22:23 -0500, Peter McAlpine wrote:
> I look forward to hearing your feedback regarding the patch and  
> feature proposal.

The patch generally looks fine.  Thanks for sticking (mostly) to the
coding style convention in the existing files ... even if it's often my
old, silly, everything( before_has_too_much_whitespace_and_after );
convention. :)

I've applied it as r15486, with the following notes and changes:

One problem I have is with the revised interface(s) for
'gnc_sx_get_instances(...)'.  By definition, disabled things don't
generate instances, so I don't see much need to have that spelled out in
the UI; the body of your 'gnc_sx_get_current_enabled_instances' can just
move into 'gnc_sx_get_instances(GDate*)' ... at least in spirit; I have
stylistic quibbles with the implementation [1].  I've made this change.

[1a]: there's no real win by constructing the list backwards and
reversing it; computers are sufficiently fast, especially for the very
small values of 'n' we're talking about here.
[1b]: while loops suck; iterations are a for-loop idiom.
[1c]: 'iterator' is never a good name; 'sx_iter' is better.
[1d]: 'filtered' isn't a great name; 'enabled_sxes' is better.

'_gnc_sx_instance_event_handler' should be modified to ignore
non-enabled SXes that it receives updates about; I've added a fixme in
the code about it.

It'd be nice to add an 'enabled' column to the sx-list model and view;
it'll become an optional column when that view switches over to using
the GncTreeView, at some point here.

There's no need to have configuration, let alone a gconf key, for the
default enabled state.   SXes are enabled by default.  I've removed
this.

Similarly, there's no need for the "newsxP" branch regarding enabled in
the SX Editor setup; the SX is already in the correct default state
(enabled) for new SXes, and its value can be set directly from the SX.

----------

The new "enabled" field represents a non-backward-compatible file
change, but that's alright ... we'll probably have others.  We should
probably just release a 2.0.5 that fixes the "XML reader doesn't ignore
elements" problem, and buy ourselves some breathing room in the rest of
the 2.x series.

Tim raises a good point regarding SXes with variables.  Similar is
multi-currency template transactions (which are actually implmented by
creating "fake" variables for the currency conversion rates).  I think
"estimation" is the right solution for both, though with the pricedb,
there's maybe a better chance of forecasting pricedb values.

In any case, there's two major options for handling the problem:

1/ handle at the SX level: in the SX editor, and probably a first-order
part of the SX itself, allow the user to define the estimation of
variables and exchange rates.

- Pros: makes sense; general purpose; durable data entry
- Cons: not used elsewhere; heavyweight; big code changes (schema,
expression parser, SX editor)
 
2/ handle in the report: somewhere in the report, allow the user to
define the estimation for variables.
- Pros: simple; isolated; solves the problem at hand
- Cons: impermanent data entry; reports are already nasty


Reports aren't naturally formatted anything like the register, though
some of the General Ledger/Jounral reports -- with the right stylesheet
-- might be a reasonable facsimile.  Do you really want it to look like
a register, or just reflect the values of the accounts?


While imagining the report itself, I note that presently the only way to
create Transactions from a set of SX instances is by actually creating
them. There's no notion of "proposed" transactions [2], and the
interface that the GncSxInstanceModel provides is only the variables
that need binding. Certainly the SXes themselves have API to get the
transaction detail, but it seems like it'd be better to have the
template-transaction -> real-transaction conversion only be in one
place.  Thus, we should probably factor out that code.

[2] GnuCash (QOF, really), makes this a bit hard since it's non trivial
to create objects that simply aren't on the Books, like Transactions and
whatnot.  Sometimes code just wants to create a Transaction and Splits
that aren't real, and shouldn't be returned in a Query or whatever.  On
IRC we've talked about some notion of an "excursion", whereby code (hey,
exactly like this report! :) could create "provisional" engine objects
that have some sort of visibility or scope.  We probably don't need to
solve that problem right now, but it bears noting.

--
...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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

SX event handler behaviour (was SX Projection Report/SX enable/disable)

Peter McAlpine-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We discussed some things via IRC but a couple questions remain...

On 31-Jan-07, at 10:39 PM, Josh Sled wrote:
> <snip>
> '_gnc_sx_instance_event_handler' should be modified to ignore
> non-enabled SXes that it receives updates about; I've added a fixme in
> the code about it.

Am I correct in that this handler exists to update an open SLR when  
SX's are edited/added/removed? If this is the case then is merely  
ignoring non-enabled SXes what we want to do?

How about this behaviour:
MODIFY event:
If instances for the SX are not found in the model and the SX is  
enabled then generate the instances and add them to the model.
If instances for the SX are found in the model and the SX is now non-
enabled then remove the instances from the model.
Otherwise the usual behaviour

REMOVED event:
No change here, if the instances aren't found in the model, then  
don't remove them, otherwise the SX was enabled and deal with the  
event as per usual.

You've got a fixme at this event but I'm not sure why. Perhaps you  
were assuming that if we ever removed an SX but no instance exists  
then it'd be an error? Now that it's possible for a SX to not put any  
instances into the model we can treat this as a potentially valid event?

ADDED event:
If the SX is non-enabled then it should not generate any new instances.

> <snip>

Hmmm, I went to look at whether I'd be able to see the 'printf("err
\n")' you put in the REMOVE event by trying to remove a SX with it's  
frequency set to "None" but I was unable to even do this. The SX  
editor popped up a dialog to confirm I wanted to set an SX that would  
never run (to which I replied "Yes") but the change to the SX was not  
saved. Strangely enough, when I went to edit it again I set the  
Recurrence Frequency to "Weekly" and was incorrectly prompted to  
confirm that I wanted to create a SX that would never run. I'm  
assuming this should not have happened this way...?

Another issue I've noticed is that the calendar should not show  
instances for non-enabled SX's or SX's that will never run (if I can  
ever create such a SX), do you agree?

Thanks for all your feedback!

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

iD8DBQFFxAeFeeKWVnwTIPIRAsBcAKDIsOtduwhAj35si/E9uYX5e5NC/QCgu12E
xheeti3FTcTktTFFx6hp0OU=
=e74x
-----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: SX event handler behaviour (was SX Projection Report/SX enable/disable)

Josh Sled
On Fri, 2007-02-02 at 22:54 -0500, Peter McAlpine wrote:
> On 31-Jan-07, at 10:39 PM, Josh Sled wrote:
> > <snip>
> > '_gnc_sx_instance_event_handler' should be modified to ignore
> > non-enabled SXes that it receives updates about; I've added a fixme in
> > the code about it.
>
> Am I correct in that this handler exists to update an open SLR when  
> SX's are edited/added/removed? If this is the case then is merely  
> ignoring non-enabled SXes what we want to do?

The handler exists to keep the GncSxInstanceModel up to date.  It
bridges the gap between QOF events and GObject signals.  One possible
listener is the SLR dialog, but the SX List and the dense calendars are
also listeners.

I was wrong about simply ignoring disabled SXes. The GncSxInstanceModel
serves two purposes: being a model of upcoming instances, but also being
a model of basic SX existance (with or without instances)... the SX List
in particular uses it for this second purpose, and needs disabled SXes
to be included.

With respect to these disabled sxes, there's the 3 users, plus the new
user, with slightly different demands on the model:

- SX List: wants disabled SXes in the model, but not projected.

- SLR: shouldn't have disabled SXes.

- dense cal: doesn't care; won't show things w/o instances anyways;
  ideally wouldn't have disabled instances included.

- projection report: wants both disabled SXes, projected out (?) nd
  enabled SXes, projected out as well (?)


Maybe, then, the callers should specify which they want in the model
they create:

   [...] gnc_sx_instance_model_new(GDate *range_end,
                                   gboolean include_disabled,
                                   gboolean project_disabled);

Following the discussion on IRC, that could be a more abstract flag
rather than a boolean, but as we don't have any other options, let's
just represent what we do have.

The model's event-handling/signaling behavior can then reflect the
creation option; there's a further wrinkle about SXes changing
{en,dis}abled state.  It should be pretty clear what the behaviours in
all cases are, along the lines you wrote, but with the new flag.


> REMOVED event:
[...]
> You've got a fixme at this event but I'm not sure why. Perhaps you  
> were assuming that if we ever removed an SX but no instance exists  
> then it'd be an error? Now that it's possible for a SX to not put any  
> instances into the model we can treat this as a potentially valid event?

The "fixme" was more about printf-based error "handling", but you're
correct: there's no error condition there ... it might be warn-level
condition, though, if we're asked to remove a non-disabled SX that
doesn't have instances.  That'd be a bit weird.


[...]
> Recurrence Frequency to "Weekly" and was incorrectly prompted to  
> confirm that I wanted to create a SX that would never run. I'm  
> assuming this should not have happened this way...?

No, that's just a bug.  I'll take a look...


> Another issue I've noticed is that the calendar should not show  
> instances for non-enabled SX's or SX's that will never run (if I can  
> ever create such a SX), do you agree?

Yup, there is nothing to show.

But ultimately, the dense cal will show whatever is represented in in
the DenseCalModel it's using.  With the model-creation API we're talking
about above, a calendar *could* be configured to show disabled
instances, though the ones that exist in the app right now wouldn't ever
do so.

--
...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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SX event handler behaviour (was SX Projection Report/SX enable/disable)

Peter McAlpine-2
Please find the attached patch:

- SX instance models properly handle SX update/add/remove events with/
without enabled transactions
- New SX editors now show non-enabled transactions

Still on my 'enabled cleanup' todo list:
- Add an 'enabled' checkbox column to the SX list dialog
- Don't show instances on the calendar for non-enabled SX's

-Peter



On 3-Feb-07, at 10:17 AM, Josh Sled wrote:

> On Fri, 2007-02-02 at 22:54 -0500, Peter McAlpine wrote:
>> On 31-Jan-07, at 10:39 PM, Josh Sled wrote:
>>> <snip>
>>> '_gnc_sx_instance_event_handler' should be modified to ignore
>>> non-enabled SXes that it receives updates about; I've added a  
>>> fixme in
>>> the code about it.
>>
>> Am I correct in that this handler exists to update an open SLR when
>> SX's are edited/added/removed? If this is the case then is merely
>> ignoring non-enabled SXes what we want to do?
>
> The handler exists to keep the GncSxInstanceModel up to date.  It
> bridges the gap between QOF events and GObject signals.  One possible
> listener is the SLR dialog, but the SX List and the dense calendars  
> are
> also listeners.
>
> I was wrong about simply ignoring disabled SXes. The  
> GncSxInstanceModel
> serves two purposes: being a model of upcoming instances, but also  
> being
> a model of basic SX existance (with or without instances)... the SX  
> List
> in particular uses it for this second purpose, and needs disabled SXes
> to be included.
>
> With respect to these disabled sxes, there's the 3 users, plus the new
> user, with slightly different demands on the model:
>
> - SX List: wants disabled SXes in the model, but not projected.
>
> - SLR: shouldn't have disabled SXes.
>
> - dense cal: doesn't care; won't show things w/o instances anyways;
>   ideally wouldn't have disabled instances included.
>
> - projection report: wants both disabled SXes, projected out (?) nd
>   enabled SXes, projected out as well (?)
>
>
> Maybe, then, the callers should specify which they want in the model
> they create:
>
>    [...] gnc_sx_instance_model_new(GDate *range_end,
>                                    gboolean include_disabled,
>                                    gboolean project_disabled);
>
> Following the discussion on IRC, that could be a more abstract flag
> rather than a boolean, but as we don't have any other options, let's
> just represent what we do have.
>
> The model's event-handling/signaling behavior can then reflect the
> creation option; there's a further wrinkle about SXes changing
> {en,dis}abled state.  It should be pretty clear what the behaviours in
> all cases are, along the lines you wrote, but with the new flag.
>
>
>> REMOVED event:
> [...]
>> You've got a fixme at this event but I'm not sure why. Perhaps you
>> were assuming that if we ever removed an SX but no instance exists
>> then it'd be an error? Now that it's possible for a SX to not put any
>> instances into the model we can treat this as a potentially valid  
>> event?
>
> The "fixme" was more about printf-based error "handling", but you're
> correct: there's no error condition there ... it might be warn-level
> condition, though, if we're asked to remove a non-disabled SX that
> doesn't have instances.  That'd be a bit weird.
>
>
> [...]
>> Recurrence Frequency to "Weekly" and was incorrectly prompted to
>> confirm that I wanted to create a SX that would never run. I'm
>> assuming this should not have happened this way...?
>
> No, that's just a bug.  I'll take a look...
>
>
>> Another issue I've noticed is that the calendar should not show
>> instances for non-enabled SX's or SX's that will never run (if I can
>> ever create such a SX), do you agree?
>
> Yup, there is nothing to show.
>
> But ultimately, the dense cal will show whatever is represented in in
> the DenseCalModel it's using.  With the model-creation API we're  
> talking
> about above, a calendar *could* be configured to show disabled
> instances, though the ones that exist in the app right now wouldn't  
> ever
> do so.
>
> --
> ...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

enabled_cleanup-r15506.diff (9K) Download Attachment
PGP.sig (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SX event handler behaviour (was SX Projection Report/SX enable/disable)

Josh Sled
On Mon, 2007-02-05 at 01:42 -0500, Peter McAlpine wrote:
> Please find the attached patch:
>
> - SX instance models properly handle SX update/add/remove events with/
> without enabled transactions
> - New SX editors now show non-enabled transactions

Looks good; r15510.  It'd be great if you could add some unit tests for
disabled SX handling in the instance model, and the {en,dis}abled
transitions, but whatever.  I've made a note in sx.rst about the tests.



On Mon, 2007-02-05 at 14:46 -0500, Peter McAlpine wrote:
> - add a check-box to the SX list tree-view to show the SX enabled  
> status.

On Mon, 2007-02-05 at 17:14 -0500, Peter McAlpine wrote:
> - don't show non-enabled SX's on the SX dense calendar

I combined these two; r15511.   There's a nasty flicker on the dense-cal
as OK is clicked, but I doubt that's related to this patch.


Thanks...
--
...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

signature.asc (196 bytes) Download Attachment