[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:       2003-12-30 14:22:27
Message-ID: 200312301522.27593.schumacher () kde ! org
[Download RAW message or body]

On Friday 12 December 2003 13:45, Best, Jan-Pascal van wrote:
> On vrijdag 12 december 2003 00:22, Cornelius Schumacher wrote:
> > Have a look at the beginChange() and endChange() methods in
> > Calendar. They are intended to do the same, but with proper locking
> > of the resources or whatever else is needed. Would that also fit
> > your needs?
>
> 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.

> That would amount to my previous patch on this, on keeping
> information about which incidences are changed in the save-ticket.
> I'm attaching it again. Can I apply this?

I don't think this is the right way. If you only intend to save a subset 
of incidences this has to be known when acquiring the lock. That means 
an additional parameter of a list of incidences could be given to the 
requestSaveTicket() function which would then only lock the 
corresponding incidences (if the ressource allows that, otherwise it 
would just lock the whole calendar instead).

> > One problem is that currently KOrganizer doesn't always calls these
> > methods when events are changed. This has to be improved.
>
> I looked at this last time. The first problem seems to be in
> CalendarView::editEvent(), where beginChange() is called. Is there is
> an editor dialog still hanging around for the event (closed or open),
> beginChange() isn't called. This may be because How can we
> differentiate between an event still being edited, and an event
> having been edited, but the event editor dialog still hanging around?

We can't. As long as an editor is open the event has to be locked. We 
could tune this by requesting the lock when starting to do changes in 
the editor and unlocking when clicking apply, but this would be more 
complex and I'm not sure, if it wouldn't be annoying, if a popup that 
the event is locked pops up when you start to type.

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