298102 - Item dialog: A merge of mozcal/sunbird event/task dialog and lightning event dialog.

Status: RESOLVED WONTFIX

(Calendar :: Sunbird Only, defect)

Description

[gekacheka]

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:

Comment 1

[gekacheka]

Attachment: screenshots of initial item-dialog design (31K)

Comment 2

[gekacheka]

Attachment: itemDialog files (content, locale, skin)

(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

Comment 3

[gekacheka]

Attachment: calendar changes to integrate item-dialog

(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.

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

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.

Comment 5

[gekacheka]

(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

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

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.

Comment 7

[gekacheka]

Attachment: itemDialogFiles (base/content, locale, theme)

(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.)

Comment 8

[gekacheka]

Attachment: calendar and sunbird changes to integrate base calendarItemDialog

(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.)

Comment 9

[Michiel van Leeuwen (email: mvl+moz@)]

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?

Comment 10

[gekacheka]

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.)

Comment 11

[Simon Paquet [:sipaq]]

(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?

Comment 12

[Michiel van Leeuwen (email: mvl+moz@)]

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?

Comment 13

[gekacheka]

(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.  

Comment 14

[Joey Minta]

(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.)

Comment 15

[gekacheka]

Attachment: calendarItemDialog0.0.3.xpi: extension to install ItemDialog in recent sunbird (save to file, then install)

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.)

Comment 16

[gekacheka]

Attachment: v3 itemDialogFiles (base/content, locale, theme)

(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

Comment 17

[gekacheka]

Attachment: v3 calendar and sunbird changes to integrate base calendarItemDialog

(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.)

Comment 18

[gekacheka]

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

Comment 19

[gekacheka]

Attachment: v4 XPI: calendarItemDialog0.0.4.xpi: extension for 0.3a1 or later sunbird, recent lightning (save to file)

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.

Comment 20

[gekacheka]

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

Comment 21

[gekacheka]

Attachment: v4 calendarItemDialog files (base/content, locale, theme)

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

Comment 22

[gekacheka]

Attachment: v4 sunbird calendar changes to integrate calendarItemDialog

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

Comment 23

[gekacheka]

Attachment: v4 lightning base changes to integrate calendarItemDialog

Comment 24

[gekacheka]

Attachment: v4 jar.mn changes (untested)

Comment 25

[Michiel van Leeuwen (email: mvl+moz@)]

Can you add some screenshots?

Comment 26

[gekacheka]

Attachment: v4 screenshots (to try, install the v4 xpi extension)

Comment 27

[Michiel van Leeuwen (email: mvl+moz@)]

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.

Comment 28

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 29

[gekacheka]

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.

Comment 30

[Fernando Ribeiro]

(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.

Comment 31

[gekacheka]

(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

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

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)

Comment 33

[Simon Paquet [:sipaq]]

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

Comment 34

[gekacheka]

Attachment: Design Considerations and v4 Open Issues (200+ lines)

(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.

Comment 35

[gekacheka]

Attachment: Item dialog 'details' disclosure button design comparison

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

Comment 36

[gekacheka]

Attachment: v5 XPI: calendarItemDialog 0.0.5.xpi (snapshot: rough separation of fields)

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)

Comment 37

[gekacheka]

Attachment: v6 XPI: calendarItemDialog0.0.6.xpi (w/field manager, see URL)

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.)

Comment 38

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 39

[cmtalbert]

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?

Comment 40

[gekacheka]

(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)].)

Comment 41

[Omar Bajraszewski]

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

Comment 42

[Simon Paquet [:sipaq]]

Since 0.7 we've moved to a new dialog.

--> WONTFIX