Re: [Evolution-hackers] Calendars and Tasks integration

[Ettore Perazzoli <ettore ximian com>]

On Tue, 2003-08-19 at 15:10, JP Rosevear wrote: 
> On Mon, 2003-08-18 at 14:36, Ettore Perazzoli wrote:
> > In Evo 1.4 the task list at the right of the calendar view just displays
> > the contents of the task list folder.  However, this doesn't fly very
> > well with the new model, since we are trying to move away from the
> > concept of a "default" folder and we're encouraging the user to use
> > multiple folders and use them at the same time instead.
> 
> We have wanted to move away from this for a while since things like
> connector require you to change your default folder in order that the
> appropriate tasks show up beside the exchange calendar.  What we really
> need to is have a one to one calendar and task association.

But how would that work exactly?  How do you represent this association
to the user?

> > The simple way to do it would be to do it like Apple iCal does it; you
> > just integrate calendars and tasks in the same object.  I.e. you don't
> > have "calendar" or "tasks" folders, but you just have "calendar and
> > tasks" folders that can contain both.
> 
> Well from a backend perspective this is not good.  As you note below, we
> have been specifically working towards separating tasks and calendars in
> order to help implementors.  If this is just a view issue then its not
> that big of a deal, although then we need a way to associate things in
> esource.

Yeah...  I am not sure how to fix this.

One way could be to allow both a calendar source and a task list source
to be associated with one URI.  Then the GUI could try to both
open_calendar() and open_tasks() for that URI, and get what it finds. 
However, this sounds yucky.

And actually, don't we need to be able to support .ics files with both
calendar and tasks items anyways (e.g. for Webcal support)?  Maybe we
need TYPE_CALENDAR, TYPE_TASKS and TYPE_BOTH or something?

(Just thinking out loud here, I am getting increasingly worried that we
haven't thought this out well enough.  :-))

> >       * UI.  We still want to have the task-only table-based list;
> >         however, it might not make sense as a stand-alone component
> >         anymore.  Maybe we could have a button (in the toolbar?) to
> >         switch to tasks-only mode when you are in the calendar?  Then
> >         you could use the same button to switch back to
> >         calendar-and-tasks mode.
> 
> Why wouldn't this make sense?  Just due to duplication?  It could use
> the same selection widget as the calendar and (like now) the same table
> widget, just not as squeezed.  I know I personally use the task
> component a lot.

Yeah, nobody (I think) wants the task list to go away.  It's obviously
an important feature.

What I wonder is whether maybe it should be a mode in the calendar
component instead of a component of its own (hence the idea of the
"zoom" button).

This might make more sense because, if all data goes into calendars, you
are basically seeing two different views of the same data (as opposed to
seeing different data, which is what the component switching buttons
normally do).

Also it might make more sense in the scenario where the components are
run independently from each other, in standalone app style...

-- Ettore