Version: 3.2 (using KDE 3.2.90 (CVS >= 20040117), compiled sources) Compiler: gcc version 3.3.2 (Debian) OS: Linux (i686) release 2.6.1dell-optiplex Opening a calendar or todo file from my desktop and saving it after changing does not store changes. I have a calender on my desktop. I started korganizer (by clicking the systray icon) I selected the file from 'recent' After making some changes I pressed 'save'. then I quit korganizer. After clicking opening the same file again I noticed that none of my changes had been saved. Notice that clicking on the file and opening a new korganizer for just that file will save changes, just not when you open it after starting from the file manu
Does it work when you open it with the "Open" action instead the "Open recent" action?
No it does not.
Confirming, I see the same problem on Mandrake 10 RC1 upgraded to latest cooker. Versions of relevant Mandrake packages: libkdebase4-3.2-47mdk libkdepim2-common-3.2-19mdk libkdepim2-korganizer-3.2-19mdk kdepim-korganizer-3.2-19mdk Observed behaviour and steps to reproduce: 0) Run korganizer 1) Use file->Open or Open recent to open a calendar from disk 2) Add a new TODO list item 3) Select File->Save (optional step) 4) Close korganizer window or quit with File->Quit 5) Run korganizer again 6) Open the same calendar 7) Outcome: the TODO item added previously does not exist There's a workaround: it is still possible to save changes to calendar, with the use of File->Close command: 0) Run korganizer 1) Use file->Open or Open recent to open a calendar from disk 2) Add a new TODO list item 3) Select File->Close 4) A dialog asking whether to save changes will appear; answer "Yes" 5) Run korganizer again 6) Open the same calendar 7) Outcome: the TODO item added previously exists, it has been saved.
Possibly related bug: bug 74439
For me this isn't just TODOs, it's also normal events. I'll save several times and later open the calendar and the added event still won't be there.
I confirm (using a Mandrake 10.0 Community). Nothing is saved (timestamps of calendar file are unmodified). SaveAs works. One other weird thing, the previously mentioned File-Close workaround does actually save the calendar, but does not close it !!
Second observation ... My (what I'd like to be) default calendar happens to be a symbolic link to another file. This worked great with the previous versions if Korganizer I used. The 3.2 version deletes the symbolic link and creates a file instead when saving (using the previously mentioned workarounds).
> My (what I'd like to be) default calendar happens to be a symbolic link to another file. This worked great with the previous versions if Korganizer I > used. The 3.2 version deletes the symbolic link and creates a file instead when saving (using the previously mentioned workarounds). Put a symlink to your wanted calendar on your desktop and click on that icon; from then on pressing 'save' works like you want it to.
I have the same bug here with a Mandrake 10 Official. If I create a new calendar and populate it with events there are saved the first time but when I quit korganizer 3.2, launch it again add new events and "Save" nothing happens. No error box are shown but data in the calendar file are still unsaved ! Same problem with a file saved locally or remotely (via fish://host/file)
*** Bug 77718 has been marked as a duplicate of this bug. ***
I run KDE 3.3.0 RPMs for SuSE 9.1 and I can verify that this behavior exists in this version as well, both TODOs and normal events. The workaround suggested by Aleksander Adamowski works however. Inspecting the calendar file reveals that korganizer does not modify the file, the changed-date does not change.
*** Bug 92673 has been marked as a duplicate of this bug. ***
Could someone raise the priority of this? It's data loss after all.
I can confirm this on KDE 3.3.2. However, I only lose my changes if I open a file using the "Recent files" menu. If I open it using File->Open, everything works and Save actually saves the file. Notice, that when a file is opened using the Recent menu, the window's title is still "Calendar - KOrganizer" (as when using the default calendar) and when a file is opened using File->Open, the title is "file_name - KOrganizer". In the latter case, changing the calendar also causes the taskbar icon to indicate that changes were made, while there is no change in the taskbar icon when the recent files menu is used. So, I can work around this, but it's really annoying still.
Thanks Michal for the analysis. Now the problem get a lot clearer. The bug is that File->Recent doesn't open the calendar in a new window, but rather the window for the resource calendar is re-used! That's bound to cause trouble. It should open a new window with that file... Cheers, Reinhold
On Thu, Feb 10, 2005 at 10:50:55AM -0000, Reinhold Kainhofer wrote: > Thanks Michal for the analysis. Now the problem get a lot clearer. The bug is that File->Recent doesn't open the calendar in a new window, but rather the window for the resource calendar is re-used! That's bound to cause trouble. It should open a new window with that file... Notice that from a usability perspective opening in the same window is the correct thing to do for many people since they will not have those resources, and effectively have an empty document. The styleguide says that you should reuse a window with an empty document on open (including open from 'recent'). So, while opening in a new window may be a solution; better marking where an (changed) appointment is stored, and flushing all changes to all stores on save seems like the real solution.
On Thursday 10 February 2005 11:57, Thomas Zander wrote: > Notice that from a usability perspective opening in the same window is the > correct thing to do for many people since they will not have those > resources, and effectively have an empty document. They will have the resources, they just might not have used them so far. A new korganizer is not really using an empty document, it's using the one static KDE standard calendar. The problem is that there is no similar thing in other applications (except the addressbook, but there it's not possible at all to open a vcard file when kaddressbook is already running). > So, while opening in a new window may be a solution; better marking where > an (changed) appointment is stored, and flushing all changes to all stores > on save seems like the real solution. That's not possible as the object for the window using for the resource calendar and the object for a calendar in a file use completely different constructors already. We can't simply switch at run-time between showing the resource calendar or a calendar in a single file. Reinhold
On Thu, Feb 10, 2005 at 11:09:56AM -0000, Reinhold Kainhofer wrote: > On Thursday 10 February 2005 11:57, Thomas Zander wrote: > > Notice that from a usability perspective opening in the same window is the > > correct thing to do for many people since they will not have those > > resources, and effectively have an empty document. > > They will have the resources, they just might not have used them so far. > > A new korganizer is not really using an empty document, it's using the one > static KDE standard calendar. The problem is that there is no similar thing > in other applications (except the addressbook, but there it's not possible at > all to open a vcard file when kaddressbook is already running). > > > So, while opening in a new window may be a solution; better marking where > > an (changed) appointment is stored, and flushing all changes to all stores > > on save seems like the real solution. > > That's not possible as the object for the window using for the resource > calendar and the object for a calendar in a file use completely different > constructors already. We can't simply switch at run-time between showing the > resource calendar or a calendar in a single file. Ok, this seems conflicting; you say that any korganizer windows has some kde-default-resources, so you suggest to open a new window for the file-resource. I think what you are saying is that an empty korganizer window already has a document open in the form of (at least) the default-resource and a new window with a specific file-resource will not have those default-resources added automatically. Right? Then you can still follow the styleguide by closing the default resources in the current window if they are empty and opening the new document in that same window. You can replace the complete view, if you want. As long as you keep using the same X-window. How does that sound?
CVS commit by kainhofe: Treat file->open and file->recent as equal (they are doing the same thing, so there's no reason to have duplicate code). This now means that a recent file is also opened in a new window (unless the current window contains an empty/new calendar file). BUGS:73017 M +7 -15 actionmanager.cpp 1.129 M +6 -5 actionmanager.h 1.50 --- kdepim/korganizer/actionmanager.cpp #1.128:1.129 @@ -235,5 +235,5 @@ void ActionManager::initActions() KStdAction::open( this, SLOT( file_open() ), mACollection, "korganizer_open" ); mRecent = new KRecentFilesAction( i18n("Open &Recent"), 0, 0, this, - SLOT( file_openRecent( const KURL & ) ), + SLOT( file_open( const KURL & ) ), mACollection, "korganizer_openRecent" ); new KAction( i18n("Re&vert"), "revert", 0, this, @@ -249,5 +249,5 @@ void ActionManager::initActions() KStdAction::openNew( this, SLOT( file_new() ), mACollection ); KStdAction::open( this, SLOT( file_open() ), mACollection ); - mRecent = KStdAction::openRecent( this, SLOT( file_openRecent( const KURL& ) ), + mRecent = KStdAction::openRecent( this, SLOT( file_open( const KURL& ) ), mACollection ); KStdAction::revert( this,SLOT( file_revert() ),mACollection ); @@ -667,4 +667,9 @@ void ActionManager::file_open() dialogParent() ); + file_open( url ); +} + +void ActionManager::file_open( const KURL &url ) +{ if ( url.isEmpty() ) return; @@ -686,17 +691,4 @@ void ActionManager::file_open() } -void ActionManager::file_openRecent( const KURL& url ) -{ - if ( !url.isEmpty() ) { - KOrg::MainWindow *korg=ActionManager::findInstance( url ); - if ( ( 0 != korg )&&( korg != mMainWindow ) ) { - // already open in a different windows, activate that one - KWin::setActiveWindow( korg->topLevelWidget()->winId() ); - return; - } - openURL( url ); - } -} - void ActionManager::file_import() { --- kdepim/korganizer/actionmanager.h #1.49:1.50 @@ -253,6 +253,7 @@ class KDE_EXPORT ActionManager : public void file_open(); - /** open a file from the list of recent files. */ - void file_openRecent( const KURL &url ); + /** open a file from the list of recent files. Also called from file_open() + after the URL is obtained from the user. */ + void file_open( const KURL &url ); /** import a calendar from another program like ical. */