From kde-pim Wed Feb 11 11:59:00 2004 From: "Best, Jan-Pascal van" Date: Wed, 11 Feb 2004 11:59:00 +0000 To: kde-pim Subject: RE: [Kde-pim] [PATCH] Server-based resources and editing events Message-Id: X-MARC-Message: https://marc.info/?l=kde-pim&m=107650074020099 > > > > 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/