Re: [Evolution-hackers] multiple calendars per view

[JP Rosevear <jpr ximian com>]

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 <jpr ximian com>
Ximian, Inc.