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

List:       kde-pim
Subject:    RE: [Kde-pim] libkcal resources (Was: location for resource framework)
From:       "Best, Jan-Pascal van" <j.p.vanbest () tbm ! tudelft ! nl>
Date:       2002-12-03 12:49:58
[Download RAW message or body]

> That's a good idea, but it would require a lot of changes to the
> way KOrganizer works. For instance, at startup KORganizer asks the
> Calendar for the events of all days in three months separately, two or
> three times. That make (2/3)*3*30 is 180/270 calls to 
> rawEventsForDate.
> 
> This should then change in a async call: "keep me informed 
> about events 
> in this period", after which the calendar sends signals when it either
> learns
> about a new event, or when something changes to an already 
> known event.
> For performance reasons, it should probably also be allowed to give a
> list
> of events (for instance for a local calendar, which can almost
> immediately 
> emit a signal with the entire calendar).
> 
> Similarly, when KOrganizer loses interest in a certain 
> period, it should
> let
> the calendar know. Then the calendar MAY free the event 
> objects it has 
> in memory, because it can now be sure that the app isn't still
> referencing 
> them.

Something like this for the ResourceCalendar (see below). A QT-problem
arises here: in order to send signal, ResourceCalendar has to be a
QObject. But then QObject already has a name property and name() and
setName()
functions. Shall I rename the Resource functions to resourceName() and
setResourceName()?

    /** Asynchronous functions */

    /**
      Request events for the given period (inclusive). This will result
      in one or more eventsAdded() signals and, in the longer term, also
      possibly in eventsModified() and eventsDeleted() signals.
    */
    virtual void subscribeEvents( const QDate& start, const QDate& end )
= 0;

    /**
      Stop receiving event signals for the given period (inclusive).
After this call,
      the calendar resource will no longer send eventsAdded,
eventsModified or
      eventsDeleted signals for events falling completely in this
period. The resource
      MAY delete the Events objects. The application MUST NOT
dereference pointers 
      to the relevant Events after this call.
    */
    virtual void unsubscribeEvents( const QDate& start, const QDate& end
) = 0;

  signals:
    // Maybe: make one signal, with bools or a flag for "is deleted" and
"is new"?
    /** These Events are added to the calendar, or they are in the
calendar
     and I haven't yet told you about them
    */
    void eventsAdded( QPtrList<Event>& events );
    void eventsModified( QPtrList<Event>& events );
    void eventsDeleted( QPtrList<Event>& events );

Cheers

Jan-Pascal
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://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]