[Chandler-dev] Custom recurrence dialog
mimi at osafoundation.org
Tue Jul 8 14:57:38 PDT 2008
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.
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.
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
> * 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"
> - 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.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev