Re: [Evolution-hackers] Calendars and Tasks integration



On Tue, 2003-08-19 at 21:44, Ettore Perazzoli wrote:
> 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?
> 
hmm, could we have that association in the backend, and a method for the
client to get the URI of the associated tasks?


> > > 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.
> 
it already open tasks and calendar, although the tasks is always the
default one. So, if we can have the backend tell the client what the URI
of the associated task folder is, it can just open that one.

but anyway, I think, at least for the local backend, it might be a good
idea to have both events and tasks on the same file. For remote
backends, we can just ask the backend for the associated URI.

cheers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]