[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 21:15:56
[Download RAW message or body]

On Saturday 06 September 2003 19:28, Reinhold Kainhofer wrote:
>
> Am Samstag, 06. September 2003 18:31 schrieb Cornelius Schumacher:
> > > 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?
>
> I'd say certainly not the latter. How is the user supposed to know
> that an event in KOrganizer is stored in a remote file? How about
> having the whole calendar on ftp or webdav?
>
> For those that have their std calendar on ftp or so and access it
> from multiple computers, we should always download the latest version
> of the file. However, for things like hot stuff this is not needed.
>
> Maybe we could a setting for remote resources which give the maximum
> time after which the calendar is downloaded again? If you set this to
> 7 days, the calendar is downloaded only every week, and in between
> the cached file is used. Two extreme cases are: always download (0
> days/mins/secs) and never download (inf days).

Yes, that's what I planned to add anyway. The problem with the alarm 
daemon is that the file might be downloaded twice, if KOrganizer and 
the alarm daemon run both. On the other hand, if they both use the same 
cache file, we could prevent this.

> > > 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.
>
> Agreed. But that menu is quite long already. IMO "Addressbook", 
> "Merge calendars", "Archive old entries" and "purge completed todos"
> do not really belong to the file menu (merge might stay there, but
> the rest is out of place there). How about adding a "Tools" menu?

A separate menu for two or four entries? I don't really like that 
solution, in particular because tools is such a meaningless name.

I think we should combine "Archive" and "Purge completed" in a common 
dialog and make this only one menu item. The same should be done for 
the "Print" and "Print Preview" actions. It would be much more 
straightforward to have both, a "Preview" and a "Print" button in the 
print dialog instead of having two different flavours of the dialog.

This would reduce the number of menu items in the file menu. The "hot 
new stuff" actions could be put into a submenu, or integrated into the 
"Import" and "Export" sub menus, so they don't make the File menu much 
longer.

> > > 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).
>
> I thought so, too. But that's also not the way it currently works.

Then we have to change it, so that it works this way ;-)

> Currently, the KOrganizer class only creates the calendar object
> itself (CalendarLocal or CalendarResources), and stores pointers to
> them, as well as pass them on to the view. Everything else is already
> done by the view (openCalendar, saveCalendar, archiveCalendar,
> closeCalendar, etc.).

Is that a problem?

> > 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.
>
> Ahm, in principle, yes. But it's much easier to use a signal, in
> particular in the ViewManager. If you create a view there, you just
> connect the signal. Otherwise the
> KOViewManager::setCalendar(Calendar*) method would have to check for
> each possible view:
> if (mAgendaView) mAgendaView->setCalendar(cal);
>
> And how would that work with the project view?

Isn't there a generic list of all views? That's why we have an abstract 
baseclass for all 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).
>
> Ahm, I meant, as a last, desperate resort I'd also do 2), because
> it's so important for KOrganizer. But I prefer not to have to dig
> into kalarmd, too. I have several kpilot issues, too, for the
> release.

Ok, I will take care of the alarm daemon.

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