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
enabled_cleanup-r15506.diff
Description: Binary data
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 ignorenon-enabled SXes that it receives updates about; I've added a fixme inthe 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 possiblelistener is the SLR dialog, but the SX List and the dense calendars arealso 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 Listin 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 anyinstances 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 inthe DenseCalModel it's using. With the model-creation API we're talkingabout above, a calendar *could* be configured to show disabledinstances, though the ones that exist in the app right now wouldn't everdo so. -- ...jsled http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
