Summary: | ics changes ignored when running together with korganizer | ||
---|---|---|---|
Product: | [Applications] ktimetracker | Reporter: | romans |
Component: | general | Assignee: | Mark Bucciarelli <mark> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dev |
Priority: | VHI | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
merges changes of korganizer and karm
I now use my ics file shared with different applications patch to react upon changes in .ics-file unified diff detecting and reacting on modification of iCal file as above, but stable |
Description
romans
2003-12-27 08:59:07 UTC
Yes, this is a know issue. I don't know if I will get this fixed by 3.2. This is the top priority on my list. okay, would it be enough to check for changes before saving ? Or am I wrong ? about that: karmstorage::save() if karmlastsaveoperationtime<filelastmodified(my.ics) { remembertimes; loadics; recalltimes; } ... let's use kdirwatch to detect changes in the .ics-file. If changed, we execute the following pseudo-code: { remembertimes; loadics; recalltimes; } On Tuesday 15 June 2004 05:10, tstaerk wrote:
> let's use kdirwatch to detect changes in the .ics-file.
this is already implemented in the resource framework. we just need to
connect slots to the appropriate signals.
i think if you grep for beginChange in kdepim/libkcal you'll see some
relevant code.
Sorry, I couldn't get this done by 3.3. Turns out the KOrganizer locking code is not working properly, and I got distracted by trying to fix that. Next release ... Created attachment 6459 [details]
merges changes of korganizer and karm
problem solved, but is this the way we want to go ?
main code for my solution. Do you want the rest ?
this code assumes that karm holds the right times for the tasks, but for the
rest (e.g. task name), the latest content of the .ics file is superior. So, if
you changed a task name in korganizer, and time was accounted in karm, it will
take the time from karm and the new task name from korganizer.
Besides the time, is there anything else karm has to remember before loading
the changed .ics ?
Created attachment 6488 [details]
I now use my ics file shared with different applications
The patch makes it possible to share the .ics file of karm between kedit and
karm. korganizer makes some problems due to wrong locking. Nevertheless you can
share the ics file between korganizer and karm.
DONE
- change a task name in kedit and save. karm takes over this change
- react on iCalFileChanged
- stop/restart timers before/after reloading
Hi Tstaerk, I don't think this is the right approach for a couple reasons. (1) There already is kdirwatcher logic in libkcal. Adding it in Karm is a duplication. (2) You cannot use kdirwatcher with all resource types; for example, a remote resource. Adding this code will make it more difficult to have Karm use different resource types. Look at libkcal/resourcelocal.cpp in the init() method. You see that the kdirwatcher dirty() signal is connected to the reload() slot. This is the code we should use. (In fact, it looks like the calendar file should automatically be reloading already?! Maybe it doesn't because of the lock?) Also, with this logic, there is no need to hold the lock for the entire session. We can change the logic to only lock when we are saving a change. Once 3.3 is out we will tackle this. Thanks for all your work! now I understand what you were talking about. Yes, resourcelocal.cpp reloads our mcalendar already. But the changes do not get into our taskview. Because taskview just sits there and does nothing when receiving the dirty signal. We then have to do a taskview->reload (and a taskview->refresh ?). And yes, this is the right way to go. resourcelocal.cpp emits resourceChanged(* ResourceLocal). IMHO, karmstorage.cpp has to connect this signal to a slot reloading the taskview from the mcalendar. Created attachment 7942 [details]
patch to react upon changes in .ics-file
This patch uses ResourceCalendar's signal resourceChanged to execute a slot
(thorsten()) everytime when the .ics file has changed. In this slot, we will
most probably reload the .ics-file. The patch adds 1 line (the signal
resourceChanged) to libkcal (file resourcelocal.h).
Is this the way to go ?
On Monday 18 October 2004 19:21, tstaerk wrote:
> This patch uses ResourceCalendar's signal resourceChanged to execute a
> slot (thorsten()) everytime when the .ics file has changed. In this
> slot, we will most probably reload the .ics-file. The patch adds 1 line
> (the signal resourceChanged) to libkcal (file resourcelocal.h).
> Is this the way to go ?
Yes.
But I think you should be able to use the
KCal::ResourceCalendar::resourceChanged() signal, instead of adding new
code to resourcelocal.h.
Also, is the signal / slot connection for the view left over code from when
you were testing stuff out? I don't see what karmstorage has to do with
the view.
Also, could you change your ~/.cvsrc to have the entry
diff -up
Unified diffs are a bit easier to read.
Thanks!
Created attachment 8007 [details]
unified diff detecting and reacting on modification of iCal file
Thanks for the info that this is the way to go. Now the same thing in a clean
form. I do not add code to ResourceLocal, just redeclared something from its
supersuperclass ResourceCalendar.
Tested it together with korganizer. Modifying a task is propagated to karm.
Created attachment 8009 [details]
as above, but stable
the double-loading feature of the patch before repeatedly caused karm to crash
when running together with korganizer. This patch uses the parameter
(ResourceCalendar *) of the signal resourceChanged to do a refresh on taskview
instead of reloading.
*** Bug has been marked as fixed ***. |