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}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070203/dab95070/attachment.bin