Re: [Evolution-hackers] Calendars and Tasks integration

[JP Rosevear <jpr ximian com>]

On Mon, 2003-08-18 at 14:36, Ettore Perazzoli wrote:
> While finishing the initial work for integrating the calendar into the
> new UI/shell framework (http://codeblogs.ximian.com/blogs/evolution has
> screenshots), I have realized we might have overlooked the basic issue
> with how to integrate the calendar and task list in the calendar view.
> 
> 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.

> So, what are we going to show there exactly?
> 
> 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.

> This model is nice, because tasks and calendars tend to be related to
> each other and having just one entity makes it simpler for the user. 
> E.g. if you create a "Personal" calendar and a "Work" calendar then you
> automatically have "Personal" and "Work" categories in your task list as
> well.

The UI for this does look reasonable.

> Also this removes the problem with what to display there altogether: you
> just display the events and tasks from the same calendar, and the
> selection in the sidebar on the left applies to both calendar and tasks.
> 
> On the other hand, there might be a few issues with this:
> 
>       * Connectors.  In Exchange, for example, tasks and calendars are
>         different entities, so how are we going to make the two models
>         go together?  We could just list everything as calendar folders,
>         although "task" type folders would only have task items in them
>         and "calendar" type folders would only have calendar items in
>         them.  Then we would have to prevent the user from shooting
>         herself in the foot by adding items to the wrong item (i.e.
>         appointments to a task only folder or tasks to a calendar only
>         folder)...  A bit messy, but it might work.
> 
>       * 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.

>       * API issues.  Should we still distinguish tasks and calendars in
>         the API?  I guess we could make it possible to have both a task
>         folder and a calendar folder at the same URI, but then does it
>         make sense that the API makes a difference between them?

Its possible but a bit untidy currently as we keep meta information in
the folder (atleast for local calendars/tasks) like the change
information.  I still like the idea of backend task/event separation for
the backends.  Currently the client API does not distinguish between
events and tasks nor will it probably.

-JP
-- 
JP Rosevear <jpr ximian com>
Ximian, Inc.