[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:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2004-01-22 22:30:58
Message-ID: 200401222330.58207.schumacher () kde ! org
[Download RAW message or body]

On Thursday 22 January 2004 14:34, Best, Jan-Pascal van wrote:
>
> Sorry I'm a but on-and-off these days, times are busy...

We all know this situation ;-)

> > > 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.

> 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.

> 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.

> 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?

> 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.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
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]