User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+ Build Identifier: windows20050601 Item dialog: A merge of mozcal/sunbird item dialog and lightning event dialog. This bug explores a merge of Sunbird's event/task dialog and lightning's event dialog into an alternative item-dialog designed with the following design and implementation choices: o Keep most of the features of the sunbird event dialog, including event/task type, priority, categories, privacy, warnings. (Drops the features that appeared incomplete: attachments, contacts) o Separate the recurrence editor into a separate dialog, like the lightning dialog (enables the start date to be seen while editing recurrence). The checkbox on the main view shows whether there is any recurrence info. o Separate other item controls into two rough kinds: * publishing fields, fields for creating or editting any event or task: title, location, attendees, start/end/due dates, recurrence, url, description. * management fields, for managing ongoing events/tasks: managing alarms, managing priority, managing categories, managing privacy, managing progress status, managing file where stored. The manage fields are hidden in the initial dialog view, so the initial view is simpler. The space is given to the description. The management controls can be exposed with a persistent more/less button. o Make the dialog independent of sunbird, so other applications can use it. * separate dtd file for locale strings. * use parameters instead of preferences, enabling different applications to manage their own preferences. (Applies to categories and weekStart). o Tasks have end dates, so they can be scheduled independent of due date. This addresses a shortcoming of rfc2445, so it uses X-DTEND as the experimental property name. o Recurrences may be specified as a list of specific dates. This addresses the problem of handling repeating events that do not follow the Gregorian calendar, such as date of full moon or related events including various traditional/religious ceremonial days. o Use some of the cleaner dialog code structure from the lightning dialog, and other general code cleanup/simplification. (forked from bug 296893 to keep discussion of this alternative separate) Reproducible: Always Steps to Reproduce:

(patch -l -p 2 -i file.patch) This patch creates files for calendar-item-dialog: mozilla/calendar/resources/content/calendar-item-dialog.js mozilla/calendar/resources/content/calendar-item-dialog.xul mozilla/calendar/resources/content/calendar-item-recurrence-dialog.js mozilla/calendar/resources/content/calendar-item-recurrence-dialog.xul mozilla/calendar/resources/locale/en-US/calendar-item-dialog.dtd mozilla/calendar/resources/locale/en-US/calendar-item-dialog.properties mozilla/calendar/resources/skin/classic/calendar-item-dialog.css mozilla/calendar/resources/skin/classic/calendar-item-recurrence-dialog.css

(patch -l -p 2 -i file.patch) This patch contains the changes to calendar files to integrate the item dialog. Since this dialog covers both events and todos, the following methods were combined: editEvent, editToDo --> editItem editNewEvent, editNewTodo --> editNewItem openEventDialog, openToDoDialog --> openItemDialog addEventDialogResponse, addToDoDialogResponse --> addItemDialogResponse modifyEventDialogResponse, modifyToDoDialogReponse --> modifyItemDialogResponse Removes the locale entries that were moved to calendar-item-dialog locale files.

I'm not sure if we need to be able to switch between event and task from inside the dialog. I tend to move it to a context menu or something, out of the dialog. On the task dialog, the start,end,due date part looks confusing. Maybe add some test like 'Planned to do this: [start] [end]', to describe what the start and end dates are for. We are trying to move general, shared files out of resources into base.

(In reply to comment #4) > I'm not sure if we need to be able to switch between event and task from > inside the dialog. Tasks and events share many fields, and there are distinct advantages to being able to switch from one to the other in the same dialog: * Users can easily see what the differences between an event and a task, and they can easily see what happens when the item type is switched: they can just change the pull down and see what fields change. * When the user drags text into a day or hour on the calendar, it starts up an event dialog at that time. If the user wanted a task, just change the item type pull down. * Everything changeable about the item should be changeable via the item dialog. Controls in other places are accellerators (like the completed checkbox, or the percent complete menu, or being able to drag an event to another time, or to another calendar). > On the task dialog, the start,end,due date part looks confusing. > Maybe add some test like 'Planned to do this: [start] [end]', to > describe what the start and end dates are for. Task start/end: Maybe can add some explanation to the tooltip. start date: if enabled, the time scheduled to start this task. end date: if enabled, the time scheduled to finish this task. due date: if enabled, the time at which this task is due. > > We are trying to move general, shared files out of resources into base. Maybe, as an independent multifile component, it could be put in its own components directory, say mozilla/calendar/components/item-dialog/{content,locale,skin}/ That makes it easier to find most of the files needed for a component so other apps or extensions can use it. http://www.mozilla.org/projects/thunderbird/dirstructure.html

the components dir is for xpcom components. The dialog isn't a component. The base dir is already there for shared files, and has base/content for ui files. Just use that structure.

(patch -l -p 2 -i file.patch) Updated patch. Moved new files into mozilla/calendar/base mozilla/calendar/base/content/calendarItemDialog.js mozilla/calendar/base/content/calendarItemDialog.xul mozilla/calendar/base/content/calendarItemDialogFactory.js mozilla/calendar/base/content/calendarItemDialogUtils.js mozilla/calendar/base/content/calendarItemRecurrenceDialog.js mozilla/calendar/base/content/calendarItemRecurrenceDialog.xul mozilla/calendar/base/locales/en-US/chrome/calendarItemDialog.dtd mozilla/calendar/base/locales/en-US/chrome/calendarItemDialog.properties mozilla/calendar/base/locales/en-US/chrome/dateFormat.properties mozilla/calendar/base/themes/pinstripe/calendarItemDialog.css mozilla/calendar/base/themes/pinstripe/calendarItemRecurrenceDialog.css mozilla/calendar/base/themes/winstripe/calendarItemDialog.css mozilla/calendar/base/themes/winstripe/calendarItemRecurrenceDialog.css Resolved issue: how to access preference information. Solution: use factory methods. factory object can be initialized with preference branch and ids to look up preferences. (Note: factory object name is calendarItemDialogFactory. JavaScript names cannot be hyphenated. The previous patch used hyphenated names for the files, but it was easy to make mistakes over which names are hyphenated and which are not. To provide one consistent name style to remember and type for calendarItemDialog files and objects, and to group all calendarItemDialog files together in the directory listing, in this patch all calendarItemDialog file names are non-hyphenated.)

(patch -l -p 2 -i file.patch) Updated patch to use calendarItemDialogFactory. - CalendarWindow now initializes and holds a calendarItemDialogFactory object. - newEvent, newToDo, and editItem now call the calendarItemDialogFactory methods. Also now patches sunbird dtd and script include files. (patch in attachment 187305 [details] [diff] [review] also reordered and added headings to calendarItemDialog.js a bit to make it a little more organized, and fixed a bug updating alarm trigger warnings.)

I fear a lot of double work is going on here. We have a lighting-dialog that looks a lot like the dialog proposed here. The main difference is that the lightning dialog misses priority, status, category and privacy fields. Before we continue to do double work, we should decide if the idea of the patches are what we want. I personally don't see a reason to not use the lightning dialog in sunbird. (Once categories are added. Even if not used a lot in the interface, just removing them would be a huge regression. Lots of user use them) Part of the problem is: lighting has the goal of being easy to use. Is that also a sunbird goal?

This dialog merges the sunbird dialog and the lighting dialog, so the lightning dialog work has been incorporated, not duplicated. I agree there is a tension between keeping a simple design for simple uses and supporting features for power uses (and interoperability with other calendar tools that use those features). One way to address the tension is to have multiple products, so you can tell users who want more than the simple product to try the more complex product, rather than adding features to the simple product. Having multiple products available can help keep the simple one simple. (Another way to address the tension is to make the design customizable so that frequent users can select the features they want without the clutter of the features they don't use.) (A third way is to make the design pluggable, so users can plug in alternatives for particular components, through extensions that override the implementation of, say, the item dialog or the time picker.)

(In reply to comment #9) > I fear a lot of double work is going on here. We have a lighting-dialog that > looks a lot like the dialog proposed here. The main difference is that the > lightning dialog misses priority, status, category and privacy fields. > Before we continue to do double work, we should decide if the idea of the > patches are what we want. I personally don't see a reason to not use the > lightning dialog in sunbird. (Once categories are added. Even if not used a > lot in the interface, just removing them would be a huge regression. Lots of > user use them) > > Part of the problem is: lighting has the goal of being easy to use. Is that > also a sunbird goal? I would say yes. Part of the ongoing work on the Sunbird UI over the last year has been to reduce the cruftiness of its UI and to make it simpler and easier to use. Part of the ongoing effort of working on a shared base should be a discussion on what is necessary in Sunbird's UI and what isn't and move the necessary parts over to the shared base and incorporate them into lightning. Mike, could you chime in, please?

We could try to crete two product, but we already lack developer time for just one product. So i say we stay focussed on one target audience. And the extension system already allows for adding items to a dialog etc, so an 'advanced user' extension can be made, if needed. The proposed patches might be a merge of the two dialogs, but the use new files etc. Why not use the existing lighting files?

(In reply to comment #12) > Why not use the existing lighting [file names]? The existing files are named 'event-dialog', and I gather the original plan was to build a separate todo-dialog. The merged dialog is for todos as well as events. The union of todos and events is called 'item' everywhere in the interfaces (such as calIItemBase), so it seems appropriate to rename it to an 'item dialog'. There were more contributors before the overhaul broke everything. I think contributors will appear once we get a working release. Overlays might be used to add fields to a dialog DOM, but they can't independently add each field to the load code, the save code, or the code that checks for inconsistencies and disables the ok button, so extending the dialog by fields seems fragile with the current architecture.

(In reply to comment #13) > Overlays might be used to add fields to a dialog DOM, but they can't > independently add each field to the load code, the save code, or the code that > checks for inconsistencies and disables the ok button, so extending the dialog > by fields seems fragile with the current architecture. What about making the event dialog "pluggable" with a function something like: registerProperty( propertyName, xulElementID, xulElementType) An overlay could then use this to add its extra fields, and onOkcommand could loop through regsitered properties and add them to the event with setProperty (). That covers load/save, and I think the overlay can/should be responsible for making sure the data is valid and enabling/disabling the OK button. This could eventually even be used by extensions to add more fields easily. (I haven't tried this to make sure it would work, but it sounds good in my head.)

This extension installs the v3 ItemDialog and calendar changes into a recent sunbird build such as 20050821, so anyone can try it easily without compiling a build. The extension adds the string CalendarItemDialog/0.0.3 to the user agent string, so it will be visible in bug reports that include the user agent string as the version number. It removes the string whenever a sunbird window is closed, so it should not persist if the extension is removed. (Works best for the common case where the user just uses one main sunbird window. It may remove the user agent string prematurely if a second sunbird main window is opened and closed while the first is running.)

(patch -l -p 2 -i file.patch) calendar/base ItemDialog additions: base/content/calendarItemDialog.js base/content/calendarItemDialog.xul base/content/calendarItemDialogFactory.js base/content/calendarItemDialogUtils.js base/content/calendarItemRecurrenceDialog.js base/content/calendarItemRecurrenceDialog.xul base/locales/en-US/chrome/calendarItemDialog.dtd base/locales/en-US/chrome/calendarItemDialog.properties base/themes/pinstripe/calendarItemDialog.css base/themes/pinstripe/calendarItemRecurrenceDialog.css base/themes/winstripe/calendarItemDialog.css base/themes/winstripe/calendarItemRecurrenceDialog.css

(patch -l -p 2 -i file.patch) addition required for calendarItemDialog: resources/locale/en-US/dateFormat.properties add 'Fifth' week string. calendar/resources and calendar/sunbird changes to use calendarItemDialog: resources/content/calendar.js calendarInit: initialize new gCalendarWindow.itemDialogFactory newEvent: call itemDialogFactory.newEventDialog with getNewEventDate newTodo: call itemDialogFactory.newToDoDialog with getNewEventDate editNewEvent: call itemDialogFactory.importNewItem editNewTodo: call itemDialogFactory.importNewItem delete addEventDialogResponse delete addToDoDialogResponse editEvent: call itemDialogFactory.editItemDialog editTodo: call itemDialogFactory.editItemDialog delete modifyEventDialogResponse delete modifyToDoDialogResponse delete openEventDialog delete saveItem resources/content/calendar.xul sunbird/content/calendar-scripts.inc add script calendarItemDialogFactory.js resources/content/weekView.js resources/content/dayView.js getNewEventDate: delete adding rounded-up time, and ensure time starts at (context-)clicked hour. resources/content/monthView.js resources/content/multiweekView.js getNewEventDate: add current time to clicked day, using item dialog factory methods to round down by default duration (make easy to add next meeting at same time as current meeting). resources/jar.mn sunbird/themes/pinstripe/jar.mn sunbird/themes/winstripe/jar.mn update jar calendarItemDialog files (mn files untested) Result works for creating fields and recurrences. Nice to see that exceptions and specific (ad hoc list) dates seem to work. (Currently there are problems with the default storage provider storing some recurrence properties, the properties do not persist, as in bug 304515. The properties are saved and loaded with a webdav ICS provider with a local file:///temp/xxx.ics as the url, so the problem must be the default storage provider, not the dialog. However, there may be other problems. I have experienced crashes when adding to an existing ics file with this dialog, and when restarting after a crash. Maybe due to saved vtimezone info. Needs further investigation and a separate bug.)

Timezone crash bug currently worked around (see Bug 305857).

Snapshot: Item Dialog v0.0.4 XPI Changes: - Updated xpi to accept Sunbird 0.3a1. - Added overlays for Lightning to xpi. Dialog changes: - Added ability to retrieve preference-based defaults for most fields, (But no preference options page UI for picking defaults yet, so currently requires setting values in prefs.js by hand.) - access keys added to many fields, to help navigate focus from keyboard. - warnings to alert user if source or target calendar is read-only. - 'details' button now has type "disclosure" so it has platform-specific disclosure styling. - aligned box widths in detail area. - calendar and category boxes take remaining width, to accomodate possible long names. - fixed bugs in date enabling that occurred changing from task to event. - fixed bugs in interaction between task date enabling and allday.

Item dialog preferences prepare for: bug 191824 default all day, bug 215975 default privacy bug 258298 default category bug 288157 default alarm, alarm precede time, status bug 312073 defaults preferences options page. Item Dialog also addresses bug 220729: ...Recurrence for specific day every Year [Nth weekday of month] bug 259478: Empty focus box next to checkmarks, looks like ... ellipsis bug 260513: Unable to unselect/clear category selection once one is chosen bug 275121: Support for recurrance on 5th [weekday] in a month bug 277274: ...include options for unscheduled recurrences [specific dates] bug 277731: no way to convert task <-> event bug 281214: All day task checkbox bug 300117: recurring event not visible on 'until' date bug 311431: Changing start day of weekly event does not remove old recur day bug 315358: Cannot set monthly recurrence

Snapshot: Code design changes - calendarItemDialog now gets defaults from a calendarItemDialogFactory. - refactored ItemDialogFactory into CalendarItemDialogFactory (base) and PreferenceBasedCalendarItemDialogFactory (derived). * factory supplies field defaults. Base prototype supplies static defaults, but may be overridden in derived prototypes. * preference-based factory supplies each field default from preferences if they exist, or from base prototype otherwise. * anticipate app extensions may create other derived factories to provide - a set of defaults per calendar, or - a set of defaults per 'template'. Next step (in progress): rearchitecting dialog code to make it easier to add dialog extensions, as jminta suggested in comment 14

(snapshot: does not include deletions from calendar.dtd from earlier patches)

Can you add some screenshots?

I tried the xpi. But i didn't try lightning a lot, so i don't know that dialog very well. All i can do is compare with the current SB dialog. Looking at it, there seem to be five changes: 1) moving attendees into a textbox, killing a tab 2) moving recurrence to a seperate window 3) moving url box to the first tab 4) removing attachments 5) reshuffling the layout with 1 to 4, there are no tabs left. I think those changes look ok, but we should be able to make them happen in a much smaller patch. Why create a new file? Reshuffling the layout can be done after 1-4 are finished, also to keep patches smaller.

This still seems fairly wide and fairly complex, visually. I'd love to hear some thoughts from beltzner about this when he gets some cycles.

Width: The description field should be wide enough to paste and edit a task outline or event abstract from a text email message without wrapping preformatted lines, typically 72-80 chars wide.

(In reply to comment #29) > Width: The description field should be wide enough to paste and edit a task > outline or event abstract from a text email message without wrapping > preformatted lines, typically 72-80 chars wide. > (In reply to comment #0) > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) > Gecko/20050531 Firefox/1.0+ > Build Identifier: windows20050601 > > Item dialog: A merge of mozcal/sunbird item dialog and lightning event dialog. > > This bug explores a merge of Sunbird's event/task dialog and lightning's > event dialog into an alternative item-dialog designed with the following > design and implementation choices: > > o Keep most of the features of the sunbird event dialog, including > event/task type, priority, categories, privacy, warnings. (Drops > the features that appeared incomplete: attachments, contacts) > > o Separate the recurrence editor into a separate dialog, like the > lightning dialog (enables the start date to be seen while editing > recurrence). The checkbox on the main view shows whether there is > any recurrence info. > > o Separate other item controls into two rough kinds: > * publishing fields, fields for creating or editting any > event or task: title, location, attendees, start/end/due dates, > recurrence, url, description. > * management fields, for managing ongoing events/tasks: > managing alarms, managing priority, managing categories, managing > privacy, managing progress status, managing file where stored. > The manage fields are hidden in the initial dialog view, so the initial > view is simpler. The space is given to the description. > The management controls can be exposed with a persistent more/less button. > > o Make the dialog independent of sunbird, so other applications can > use it. > * separate dtd file for locale strings. > * use parameters instead of preferences, enabling different applications > to manage their own preferences. (Applies to categories and weekStart). > > o Tasks have end dates, so they can be scheduled independent of due > date. This addresses a shortcoming of rfc2445, so it uses X-DTEND > as the experimental property name. > > o Recurrences may be specified as a list of specific dates. > This addresses the problem of handling repeating events that do not > follow the Gregorian calendar, such as date of full moon or related > events including various traditional/religious ceremonial days. > > o Use some of the cleaner dialog code structure from the lightning dialog, > and other general code cleanup/simplification. > > (forked from bug 296893 to keep discussion of this alternative separate) > > > Reproducible: Always > > Steps to Reproduce: > I have same features requests to UI event/tasks dialog. I don't know where i can to post this news features requests, then i'm putting here. 1) Allow to send a notification if the attendee have conflict of time in new event. 2) Allow to show time available of the attendees. 3) Allow to suggest one or more times available. 4) ACLs to allow others users to access your calendar (read and write). (to secretary change events of boss by example). 5) Allow handheld integration. 6) Allow to show a window of time of the attendee (example: i have between 02:00PM and 04:00PM free to new events. And other users can to see this window). 7) Allow a user to set a window time to work with item 6. 8) Allow a user to remark and/or cancel the new event: 8.1) Allow a attendee to suggest new times of the event; 8.2) Allow to remark the event by author or attendee; 8.3) Allow to send a notification of remark or cancel of the event. Thank you a million.

(In reply to comment #30) > I have same features requests to UI event/tasks dialog. I don't know where i > can to post this news features requests, then i'm putting here. Thanks, however these are all beyond the scope of this bug. Please file feature requests as a new bugs, with severity 'enhancement'. https://bugzilla.mozilla.org/enter_bug.cgi?product=Calendar&format=guided

Quick and dirty design thoughts: * focus on the primary tasks that a calendar user has - name the event - specify a length for the event - specify repeat options for an event * not sure that the URL field should be in the primary section * more empty field space makes the dialog look more complicated, if you need that width, then use two columns to get more space efficiency and reduce the number of empty pixels that distract the eye * the [+] / [-] widget is inconsistent and not the best choice for showing more/less information within a dialog. Instead use either a HTML link-like "See more details ..." or a [More >>] / [ << Less ] button. Mike's quick suggested refactoring: Name : [________________________________] Type: [Event |v] Location : [________________________________] Attendees: Start : [December 18, 2005 |v] [12:00 |v] .--------------------, End : [December 18, 2005 |v] [ 1:00 |v] | | [ ] Repeats [ Settings ...] | | '--------------------' [ << Less ] Description: .----------------------------------------. | | Alarm: | | Task Status: | | ... '----------------------------------------' (heh, I didn't have time to finish, but you get the picture)

*** Bug 322193 has been marked as a duplicate of this bug. ***

(In reply to comment #32) > ...focus on ... primary tasks ... > ...not sure URL [or description] should be ... primary ... > ...[quick design moves description to details]... Thanks for your quick thoughts. One of the controversies of the item dialog is that people use calendars in different ways, so fields that are 'primary' for some are not used by others and vice versa. (One thing I'm working on now is to make the implementation of fields more independent so fields can be added/removed/replaced via extensions and overlays.) Attached are some of the considerations that have informed the design up to v4, and some open issues.

Here is an illustration of the minor issues that led to the current design using a twisty for the 'Details' disclosure button. A [Details>>] button at left - takes up more space (widens column and thickens row) and - seems too heavy among the labels. A smaller, less heavy control would be preferrable. A Dialog Disclosure button next to the OK Cancel buttons - takes no additional space, but - is positioned inconveniently for mousing: have to move to corner then back - is positioned very inconveniently out of order for tabbing: if tabbing through fields, from description (just above the details bar) have to tab past the ok button to get to the disclosure button, then have to shift-tab backwards to get back to all the fields. The button needs to be at the boundary, both visually and in the tab order The twisty disclosure button - takes less space than a full button - is positioned in order at the border

This xpi contains a snapshot of a first cut at separating code for itemDialog fields so they can be changed independently. (No need to look at it, it will be superceded soon.) The initial separation makes it easier to add new fields. Functions are separated into loader, initializer, listeners, checker, and saver for each field. So to add new fields, just need to add the necessary functions to a list rather than change an existing function, so multiple extensions that just add fields don't overwrite each other's changes. Its shortcoming is that it does not make it easy to remove fields, particularly the listeners associated with the fields. Another problem is that the code needs to be refactored so it can be reused in more than one dialog (too much is repeated in the the recurrence dialog). The next version addresses these shortcomings. It adds a 'FieldManager' object to manage everything. I'm testing it by writing some simple extensions, and updating the architecture as needed to make sure it is possible to write the extensions, such as. - add simple text field: Resources property - remove simple field: attendees (so the current field can be replaced) - replace field: replace End date with Duration (bug 274095)

This version of ItemDialog registers field loaders, savers, propagators, listeners, and checkers with a FieldManager, so extensions can remove listeners to remove or replace a field. Hidden contributions of ItemDialog: * designed for multiple/context-dependent defaults (not hardcoded prefs) * defaults pane layout is same as item dialog * designed for multiple extensions (no monolithic loader/saver functions) * fields are removable (listeners registered with a field manager) * field manager scans common listener code to find fields read and written. * field manager reports errors with location of caller. * units label/menulist are localizable (not just english singular+plural) Example extensions to this ItemDialog can be found at the URL below. The example extensions show how to * remove fields not needed (and listeners) * move fields (dom) * add text field (resources) (loader/saver/pref) * add datetime field (opening date) (loader/saver/listener/checker) * replace a datetime field (replace end with duration) (complex listeners) * replace a field with a dialog (attendees) Attendees dialog extension edits the calIAttendee fields, so it may be useful for input if anyone is working on an attendee backend. In Lightning, Attendee dialog extension enables picking from list of addresses from addressbooks. Some of these ideas may be useful for other event/task dialogs. Longer descriptions with images of the dialog and each of the extensions can be found at http://www.geocities.com/gekacheka/moz/cal/ItemDialog/index.html (Sorry for the delay... some of the code which ItemDialog integrates with started changing frequently, so this waited for 0.3a2.)

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o Bugspam filter: TorontoMostafaMove

gekachecka, Can you comment on how this bug fits into the current 0.5 release strategy? It seems to me that the original impetus for this was that the Sunbird and Lightning Event Dialogs needed to be merged. That has since happened, and the Event Dialog is currently changing further by the prototype work of the Sun folk. You've obviously done a ton of work here, and some of this may be duplicated by the current code, and some may not, so what should we do with this bug? In particular these are my questions: * Should we re-asses the blocking list on this bug? Does it make sense to have all those bugs blocked by this one? * Should we create spin-off bugs to encapsulate items from some of the patches for this bug so that they can be easily incorporated into the current Sunbird/Lightning Codebase? * Should this bug be resolved, or should it remain open?

(In reply to comment #39) > Can you comment on how this bug fits into the current 0.5 release strategy? Other project members expressed that the added features are not needed by the current target audience. So I understand this dialog might be an alternative dialog for users who need the features rather than as the primary dialog. In any case, the priorities in the 0.5 roadmap are not on these features, so they are in prototype development. Even if the dialog UI is not used, some of the architecture could provide a common foundation for each of the dialogs if the flexibility they provide is desirable. In particular: multiple item factories which fill new items with defaults before passing them to the dialog [per calendar factories not yet demonstrated], and the field manager to manage loading, saving, checking, and updating related fields in a way that permits extensions to add/remove/replace fields. But I understand these architectures may be viewed as unwanted complexity if these features are not a priority for a release, in which case they could be confined to this dialog. > * Should we re-assess the blocking list on this bug? Does it make sense to have > all those bugs blocked by this one? They are dependent on this one in that this dialog provides an implementation that addresses the feature request. This is not to say that other dialogs cannot also provide an implementation. > * Should we create spin-off bugs to encapsulate items from some of the patches > for this bug so that they can be easily incorporated into the current > Sunbird/Lightning Codebase? I assume that will be necessary if/when such desired pieces are identified. A prototype is good for trying a combination of ideas but reviewing them will take separate smaller patches. Did you have particular issues in mind? > * Should this bug be resolved, or should it remain open? I vote for keeping open, but maybe retitled since the scope of the prototype has increased beyond simply merging the UI. Maybe "Item Dialog: prototype event/task dialog with multiple defaults and extensible/replaceable fields, merged from mozcal/sunbird/lightning.", but that is a bit long. (Thanks for your interest. I'm working on updating the XPI, but have run into some event issues/bugs [such as bug 361893, and paneload event listeners in the preference manager don't work as I expected (just reading the DOM in a overlay paneload listener breaks things in strange ways, maybe the overlay process is not really complete)].)

(In reply to comment #0) Is the bug still valid? Prototypes are enabled by default now.

Since 0.7 we've moved to a new dialog. --> WONTFIX