Version: (using KDE KDE 3.1.94) Installed from: Gentoo Packages when i have both karm and korganizer running with the same .ics file the following happens: - if i change anything in karm, changes appears in korganizer instantly - if i change anything in korganizer, karm ignores changes, does not reread changed file and will overwrite it if this is supported, karm should check if file was modified externaly while it is running and re-read it. thank you.
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 ***.