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

List:       kde-pim
Subject:    Re: [Kde-pim] Planned fixes for KOrganizer in KDE 3.2
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2003-09-06 16:31:24
[Download RAW message or body]

On Saturday 06 September 2003 14:46, Reinhold Kainhofer wrote:
>
> NECESSARY / critical:
> ================
>
> 1) Fix KOrganizer's session management (bug:49356)
> Also, I think we should have a menu item "Open standard calendar"
> (maybe needs to be better worded). Currently, you have to start a new
> KOrganizer to get the resource calendar.

Agreed.

> 2) Update kalarmd to use CalendarResources instead of active calendar
> config entries (would also fix bug:41113, bug:52027 and bug:53967)

I'm not sure how to handle remote resources. Should the alarm daemon 
repeatedly download files or should it only use the last cached version 
or should we disable alarms for remote files?

> 12) Move "get hot new stuff" to a better menu position, and allow to
> create a network resource instead of merging it into the local
> calendar file (bug:60954, bug:60951, bug:60955)

I would propose to move the "new stuff" actions to the file menu.

> COMMENTS:
> =========
>
> ad 1) As discussed in N7Y. I started some work on this, and I'd
> propose we let the CalendarView do all the calendar management (which
> is currently done by KOrganizer or the part). In particular,
> KOrganizer would no longer create the calendar (not even have a
> pointer to it. It's not necessary, the CalendarView has the pointer
> and KOrganizer can access it). Currently, the constructors of
> KOrganizer and KOrganizerPart duplicate the whole code for creating
> the resource calendar, so let's just move that code to CalendarView.
> When session management tries to load the resource calendar, the
> CalendarView would load it, and emit a setCalendar(Calendar*) signal,
> which is connected to all views, which have a pointer to the calendar
> stored, or which need to do some initialization/update with the new
> calendar.

I don't think it's the right solution to move the Calendar creation code 
to CalendarView. We should keep the separation of the document 
(Calendar) and the view (CalendarView).

The duplicated code could as well be put in a shared class like the 
action manager.

Updating of the views needs not be done by signals. CalendarView can 
directly call the update functions of the individual views.

> I already started working on 1), 3), 9), 11), 14), 19), and 21), so
> some patches might be ready in the near future.
> I would also volunteer to tackle 5), 7), 8), 12), 17), 18) and 20),
> if needed, maybe also 2).

That leaves 4) (DCOP Interface), 6) (Kontact integration), 10) 
(reminders for recurring events), 13) (military time format), 15) 
(passive alarm popup), 16) (turn recurring instance in own event),

There are several people working on 6), the other topics would be nice 
to have fixed, but I wouldn't consider this highest priority. Let's see 
what we find time for.

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