So, with Nick Parlante's most excellent patch for Bug 8087 (Support
more recurrence rules), we have a nifty custom recurrence dialog
(patch attached to that bug). However, there are a few questions that
have come up that I'd like to air out here rather than in the bug:
* Highly custom recurrence: While the dialog does support some useful
recurrence rules beyond the pre-existing set, it doesn't cover the
full gamut of what's available in icalendar. Some examples include:
- recurrence defined by a series of RDATEs rather than an RRULE
- recurrence defined by more than one RRULE
- complex combinations of RRULE parameters (e.g. the "payday rule"
FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1)
- sub-day occurrences, i.e. BYHOUR/BYMINUTE/BYSECOND
With this in mind, what's the best way in the UI to indicate that the
user may not want to edit the rule because of potential data loss?
* The WKST parameter. Currently Jeffrey is of the opinion that we
should not set WKST if the user can't actually edit it. However,
apparently Katie had some issue with that ... Katie, could you let us
know what that was? Also, I believe dateutil.rrule generates a wkst
internally, unless I've misunderstood the code, so that might be
tricky to avoid.
* Testing for equality: Given the amount of change that can take place
when we alter an event's recurrence, it is probably wise to have the
code do nothing if the user makes no changes. Jeffrey had sketched out
a way to do that, based on the dictionary of rrule key-value pairs
that the dialog returns. However, right now we don't have code to
convert the input rrule into such a dictionary, although it could
probably be written straightforwardly. Possibly there's another
approach (like noticing when the user change the UI) that would work
better.
* Modal dialog: As mentioned by Heikki in the bug, it would be nice to
have this not be a modal dialog. Unfortunately, the wx functionality
to do this (wx.PopupTransientWindow/wx.PopupWindow) are not
implemented on some platforms, so this would take some work, unless
someone knows of a better way here.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
