[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    RE: [Kde-pim] [PATCH] Server-based resources and editing events
From:       "Best, Jan-Pascal van" <j.p.vanbest () tbm ! tudelft ! nl>
Date:       2004-02-11 11:59:00
Message-ID: A2D0261FA99B9C40AEA56D1D44468CE8D0FB4A () TBM0EXCH2 ! tbm ! tudelft
[Download RAW message or body]

> > > > We could update the changed resource in endChange(), 
> but it would
> > > > be nicer to store information on which incidences have been
> > > > changed in the save Ticket, and then update all changed
> > > > incidences in one go.
> > >
> > > Which incidences have changed is something the resources can find
> > > out internally. This doesn't have to be refelected in the API.
> >
> > Actually, they cannot. How would a resource know which incidences
> > have been changed by the UI?
> 
> If it's only in the GUI the resource doesn't have to know. If it's 
> changed in memory but not yet written back. The resource gets to know 
> by the IncidenceObserver.
It does - but not just once. When I edit an event in the GUI (name, location
and start time) and press OK, incidenceUpdated() is called nine times,
since it is called every time one of the Event::setXXXX() functions is
called. That about makes it useless for my causes, since I don't want 
to upload the event to the server nine times.

But I can think of a combination: keep a list of "dirty" events, and write them
to the server at endChange(). We just need to make sure that endChange() is 
called properly.

> > I still think a better way would be to use signals for the
> > communication between CalendarResources and the resources. I've
> > implemented this for the Exchange resource, which can now have the
> > GUI update properly when the data and the server changes
> > (new/modified/deleted event), and also relay GUI actions (again,
> > new/modified/deleted event) to the Exchange server. See attached
> > patch for what would be needed in korganizer and libkcal.
> 
> The signals for notification of changes to single events are 
> nice. They 
> might be more efficient. On the other hand I would consider this an 
> optimisation which can be done when all the fundamental problems are 
> solved.
OK, we'll keep those for now. As optimisation, you mean e.g. to pass a list
of added/modified/deleted events? I can imagine some cases for which some
GUI flicker could be reduced. We can change that later.

> > For "upstream" changes, from the server through the resource, the
> > CalendarResources, to KOrganizer, the resource monitors the server
> > and when a change happens, it fires an eventAdded( Event * event ),
> > eventModified( Event * oldEvent, Event * newEvent ) or an
> > eventDeleted( Event * event )signal.
> > The CalendarResources relays these signals to its own
> > signalEventAdded(), etc., signals. The KOrg::ActionManager connects
> > these signals to the eventAdded, eventDeleted and eventChanged slots
> > of the CalendarView.
> 
> eventDeleted() is tricky, because you have to make sure that 
> the event 
> actually isn't deleted when the signal is sent, because the event 
> object is passed as argument.
Should I rename it to eventToBeDeleted()?

> > The patch adds a call to mCalendar->eventChanged() for modified
> > events in KOEventEditor::processInput().
> > CalendarResources::eventChanged() finds the proper resource 
> and calls
> > its eventChanged(). The Exchange resource then updates the event on
> > the server.
> 
> Why don't you use the IncidenceObserver and the beginChange(), 
> endChange() functions. Shouldn't they provide the same functionality?

I'll try, see above.

> > As I said, I've implemented this for the Exchange resource. Nothings
> > needs to be changed for other resources, although I can 
> imagine other
> > server-based resources would also implement this. For the file
> > resource, the "upstream" is of course irrelevant, since the 
> ical file
> > won't change by itself; the "downstream" is currently handled by
> > calling the save() method when changes happen. We could 
> leave it like
> > that, or, internally in the resource, call save() when 
> eventChanged()
> > is called.
> 
> I really don't like the eventChanged() function because it's 
> redundant. 
> The Calendar holds a pointer to the event object. When the object is 
> changed by the GUI it actually is also changed for the resource. 
> Requiring to separately notify this change doesn't feel right 
> to me. If you don't do it you will get inconsistencies.

I don't think it is redundant, since merely changing the event object in
memory does not tell the resource that the event has changed: to find that out
it would have to iterate over all (possible 1000s of) events and 
compare them all with *copies* to see if something changed.

But since the same functionality can be had (hopefully) with a combination 
of begin/endChange() and IncidenceObserver, I'll try and use that.

Jan-Pascal



_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]