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 _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
