If there is a recurrence rule that we do not support, can we first
pop up this message and then replace it with the recurrence rule
editing UI if the user chooses to continue.
*******
Currently, Chandler does not support
editing this recurrence rule: xxxx
If you continue to edit, you will lose the
current recurrence rule.
[Cancel] [Continue]
*****
It would be nice to try out the "sheet-dialog" even if only on Linux
and Windows. However, if this creates extra work, I think we should
punt it to Future. It would be better for us to switch all modal
dialogs to the sheet-dialog anyway, preferably on all 3 platforms.
Mimi
On Jul 8, 2008, at 2:27 PM, Grant Baillie wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
