Re: [Evolution-hackers] multiple calendars per view

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.

> > So, the simplest solution I can think of is to have the GnomeCalendar
> > manage the list of ECalendarModel's (one for each calendar) and pass
> > that to each view in the 'update_query' virtual method. Then, each view
> > just has to draw each event, identifying each one with the CalClient it
> > belongs to.
> > 
> > This way, all the query management would be done in only one place (the
> > GnomeCalendar) and views would just have to draw the events from the
> > calendar models they get in the update_query method.
> Can't the views have their own models for which GnomeCalendar can change
> the rows and such? 
yes, in fact, they would need to have their own models, since the query
is not the same for all views (the time range changes).


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