Re: [Evolution-hackers] multiple calendars per view

[Rodrigo Moya <rodrigo ximian com>]

On Wed, 2003-07-30 at 16:55, JP Rosevear wrote:
> On Sun, 2003-07-27 at 12:33, Rodrigo Moya wrote:
> > On Fri, 2003-07-25 at 22:22, JP Rosevear wrote:
> > > On Thu, 2003-07-24 at 17:04, Rodrigo Moya wrote:
> > > > Hi
> > > > 
> > > > Here are all my thoughts on the implementation of having multiple
> > > > calendars per view.
> > > > 
> > > > First, JP and I have agreed on having the views use ECalendarModel, like
> > > > the task list. So, given the current situation in E*View, I've thought
> > > > about removing all the CalQuery usage in both EDayView/EWeekView, and
> > > > have their 'update_query' virtual method be called, from GnomeCalendar,
> > > > with the ECalendarModel to display.
> > > >
> > > > This is quite easy to do, a bit tricky, since it involves some more
> > > > refactoring of the EDayView/EWeekView code, but shouldn't take long at
> > > > all.
> > > > 
> > > > The other part is to integrate multiple clients (that is, multiple
> > > > ECalendarModel's) in this stuff. We need to have each drawn event in the
> > > > views be associated with a CalClient (ie, a CalClient * member in
> > > > ECalViewEvent), so when calling the update_query virtual method, we need
> > > > to have a way to inform the views to which CalClient's each object
> > > > belongs to, so that it can associate them to the drawn events.
> > > 
> > > Can't the model handle this type of thing?  Or do we need it for special
> > > handling in some cases (like instance stuff)?
> > > 
> > yes, we need in some cases to access the underlying CalClient (resizing
> > an event, instance stuff, ...). But yes, we could have the model manage
> > all, provided that it associates each component with its client.
> 
> I think it should, because it has to do that in the etable/etree case
> anyhow.  Do you think that the same model can be used for both a tasks
> list and an event list?  If not (the current calendar-model has some
> task specific stuff in it) can we make a generic model and then subclass
> it?
> 
yes, indeed it can be used. As we talked on IRC, the plan I've came up
is:

* write a ECalModel class that contains all the component and query
management. For each component, it will store its icalcomponent and the
CalClient to which it belongs.
* write a ECalModelTasks and a ECalModelEvents classes, based on
ECalView, and which implement the column mapping for the model for tasks
and events respectively.
* change the views to use ECalModel for getting the components.
* then, add code to the views to colorize each item depending on the
CalClient they belong to.

This is grosso modo what would be needed.

cheers