[Chandler-dev] Custom recurrence dialog

[Mimi Yin]

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