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

[Peter McAlpine]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: enabled_cleanup-r15506.diff
Type: application/octet-stream
Size: 9558 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070205/269d1e57/attachment.obj 
-------------- next part --------------

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}

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070205/269d1e57/attachment.bin