Re: [Chandler-dev] Custom recurrence dialog
Mimi Yin <mimi-6zGkXsw2EZWGJGYlWa3Ukdi2O/[email protected]>
| Newsgroups | gmane.org.osaf.devel |
|---|---|
| Message-ID | <[email protected]> |
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