- Wednesday, November 1st, 17:00 UTC
- NOTE THE TIME CHANGE TO 17:00 UTC! YOUR LOCAL TIME DOES NOT CHANGE!
- Phone meeting
- Join #calendar-mtg on irc.mozilla.org for attendance
- Toll free numbers
- US/Canada: 800 867 8609
- Netherlands: 08002658232
- Germany: 08001014546
- Poland: 008001114706
- Sun: x44444
- More numbers (toll/toll free): Sun Worldwide Ready-Access numbers
- Access Code
- Conference controls
- *6 mute line
- *7 unmute line
- Each time you say something, please say your name first so people know who's speaking
lilmatt, jminta, daniel, christian, ssa
lilmatt and mvl polished the 'Toronto list' and created a road map from it which can be found here: Calendar:Roadmap The Next Release Status page is now in a similar shape than the one for the 0.3 release which gives a good overview.
We basically went through the Calendar:Next_Release page and discussed the current status. Here it is:
The patch that uses a controller to act on the data was landed this week.
Regarding item editing we discussed if we want to allow for changing only future occurrences of a series instead of changing all occurrences. At least iCal provides this option by splitting the series at the occurrence where you started editing. We all agreed that this is a reasonable approach. The only question was if we want to keep the 'change all events' option, which would result in 4 buttons in the corresponding dialog (i.e., change all events, change only future events, change only this event, cancel).
Christian will compare how existing calendar applications behave here and post the results.
mvl: is working on an index patch joey: wants to skip properties in certain cases to speed up data access daniel: there was a comment from an sqlite guy who offered to provide better indexing support, this will probably require a schema change lilmatt: already checked in schema check to warn about changes, should make future schema changes a little more safe ssa: the performance improvements we are investigating are more view related and will trigger the providers less often (reduce multiple reads etc.)
Christian's pain points list still under construction, currently prioritizing, thinking about what functionality is really needed in certain situations, etc. will send something out this week
ssa's list regarding task handling is upcoming: how can we incrementally improve task handling and what are the currerent issues dmose: if the RFC2445 has issues regarding task handling let's try to improve the 'standard' joey: another way to say it: find out a good solution for the user first and then try to map it onto RFC2445
is making progress there are issues especially for the tbird/lightning case because tbird needs to be registered for eg .ics, on mac this is stored in plist's that extensions are not supposed to change
lilmatt: boils down to how to sync without hosing the users data completely ?
now available for lightning ! but only on calendar menu not in file->print tbird handles enabling of menu items in a very special way, so we don't have this now, requires overriding existing commands, may be when a calendar view is in front
may be low priority
get data in
lilmatt: vcalendar/vtimezone/valarm require proper x-prop handling -> may be mickey can have a look at it
imip/itip ongoing (clint)
we have issues with foreign timezones and x-properties not surviving round trips or even cloning
user pain-points from 0.3
24hour views: (discussion) make box sizes always as high so that working hours fit. adding working hours as opposed to viewing hours as next step, let scroll beyond the working hours, may be we need working and viewing hours christian: not important to distinguish between working and non working hours but only hours of interest, when you scale the window the grid should be fixed and display more hour boxes, they should scale in width only ssa: tbe, who was in charge of the 24 hrs view changes, is working on wcap subscriptions for the next weeks so may be this will rest for a while lilmatt: regarding subscriptions tbe should look at how webdav does it, there seems to be a similar feature, i.e. multiple calendars on the same server