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