[Chandler-dev] Custom recurrence dialog
Katie Capps Parlante
capps at osafoundation.org
Wed Jul 9 15:34:17 PDT 2008
Grant Baillie wrote:
> * 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.
In the bug, Jeffrey brought up the case of people switching locales
(changing the wkst) causing surprising behavior given that you can't set
the wkst from the UI.
My point is that the calendar UI *does* have a user visible week start,
whether or not the user can change it. Not setting it in the custom
weekly case causes a behavior that is surprising to the user, which I
ran into very quickly when hacking around to understand how the
recurrence code worked. (I assume wkst is only set in the custom weekly
case, which is also what I observed in iCal).
Create an event on Sunday, set it to recur every Tu/Th, every 2 weeks,
and you see no events on Tu/Th. The week "ended" on Sunday so the next
event is in 2 weeks -- which is counter to what the user expects given
that the calendar they are staring at appears to start on Sunday.
Anyhow, it is perhaps such an edge case it is not that important, but
that was my argument.
(A side note, we do have a separate bug for being able to change the
week start from the UI:
> * 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.
Is the performance gain noticeable enough to make this a priority? It'll
be a relatively rare event, assuming we notice the "no changes" case if
no customization is involved.
> * 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.
I think sticking with the modal dialog is fine for 1.0.
More information about the chandler-dev