Bug 49356 - session restores wrong calendar file
Summary: session restores wrong calendar file
Status: RESOLVED FIXED
Alias: None
Product: korganizer
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Cornelius Schumacher
URL:
Keywords:
: 59390 59592 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-10-18 18:28 UTC by Martin Koller
Modified: 2004-09-15 00:21 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Koller 2002-10-18 18:28:34 UTC
Version:           pre3.1rc1 (using KDE 3.0.8 (KDE 3.1 beta2))
Installed from:    compiled sources
Compiler:          gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
OS:          Linux (i686) release 2.4.17

In my .kde/share/config/session/korganizer_... file I have the first lines with:
[1]
Calendar=file:/root/.kde/share/apps/korganizer/martin.ics

But when I log into KDE the next time it always opens a "New Calendar" and not the one mentioned above.
Also, korganizer is restored always on Desktop one, but before logging out I had in on desktop two.

Below you find the full session-file:

[1]
Calendar=file:/root/.kde/share/apps/korganizer/martin.ics

[KOrganizer MainWindow Toolbar style]
Hidden=false
IconSize=22
IconText=IconOnly
Index=0
NewLine=false
Offset=-1
Position=Top

[KOrganizer MainWindow korganizer_toolbar Toolbar style]
Hidden=false
IconSize=22
IconText=IconOnly
Index=1
NewLine=false
Offset=-1
Position=Top

[KOrganizer MainWindow schedule_toolbar Toolbar style]
Hidden=false
IconSize=22
IconText=IconOnly
Index=2
NewLine=false
Offset=-1
Position=Top

[Number]
NumberOfWindows=1

[WindowProperties1]
ClassName=KOrganizer
Height 1050=977
MenuBar=Enabled
ObjectName=KOrganizer MainWindow
StatusBar=Enabled
Width 1400=1392
Comment 1 jensen 2002-12-26 19:11:55 UTC
This session management bug is still present in KDE_3_1_BRANCH, but  
I don't know about head.  It has two parts  
  
1) KOrganizer is always started on desktop 1 instead of its last desktop  
2) KOrganizer starts with a new calendar instead of the active one 
  
This bug is quite old, although it was fixed as #19922 for KDE 2.1b2. 
Comment 2 Michael Hanke 2003-02-03 08:45:11 UTC
This bug is still existent for my kde3.1 final using SuSE 8.1 rpms. 
I have korganizer on desktop 1 anyways, but at every new session I have to open recent 
files-> mycalendar.ics  for my calendar to become active, though the korganizerrc says to 
use it directly. Maybe my config files are tainted by a recent installation of kde3.1 RCs?  
 
good luck 
michael 
Comment 3 Brian DeRocher 2003-04-04 16:54:53 UTC
Since KOrganizer didn't restored my calendar when KDE started up, my alarms didn't 
remind me about a meeting, and consequently i missed it.  I'm sure this happens to 
many people.  My point is, this bug causes a loss of production, and that's why i think it's 
important to fix. 
Comment 4 Richard Bos 2003-04-14 21:45:21 UTC
I agree with Brian DeRocher one can miss meeting and appointments if the 
wrong calender is used.  Please, have this fixed. 
 
(SuSE-8.1 kde-3..1.1 rpms) 
 
Comment 5 Til Schneider 2003-07-15 15:48:51 UTC
I think these are two bugs: 
1. KOrganizer starts on the wrong desktop 
2. KOrganizer always starts with a new calendar 
 
The 1. bug does NOT happen on my machine. I use KDE 3.1.1 with SuSE 8.2 and KOrganizer 
is on Desktop 4. The next time I start my computer it is still (as expected) on Desktop 4. 
 
But the 2. bug happens on my machine, too. KOrganizer should reload the last opened 
Calendar. 
 
Please fix this one, it will solve many user's problems. And I think it shouldn't be hard to fix 
this... 
Comment 6 Reinhold Kainhofer 2003-07-31 11:47:29 UTC
*** Bug 59390 has been marked as a duplicate of this bug. ***
Comment 7 Reinhold Kainhofer 2003-08-07 19:33:25 UTC
Subject: kdepim/korganizer

CVS commit by kainhofe: 

Let the session management also write out if we use the resource calendar. This is the first part to the solution of bug #49356. The other part, loading the resource calendar or the appropriate calendar file, is much harder and requires deep changes in the KOrganizer class:

In the constructor of KOrganizer the calendar - either CalendarLocal or CalendarResources - is already allocated using the bool document parameter. So from then on it is already determined whether we use a local calendar file or the system-wide calendar. Session management, however, first creates a new KOrganizer(), i.e. bool document always has the default value true so no resource calendar will ever be restored, and only then it calls readProperties, which cannot create the CalendarResources any more.

But there is also another problem. Although all config settings are correctly written out to the session management's config file, on login only the very first of the windows is actually restored. This happens also if the config file says that there are 3 windows or so.

CCMAIL: 49356@bugs.kde.org


  M +13 -4     actionmanager.cpp   1.28


--- kdepim/korganizer/actionmanager.cpp  #1.27:1.28
@@ -979,17 +979,26 @@ KURL ActionManager::getSaveURL()
 void ActionManager::saveProperties(KConfig *config)
 {
+  config->writeEntry( "UseResourceCalendar", !mMainWindow->hasDocument() );
+  if ( mMainWindow->hasDocument() ) {
   config->writePathEntry("Calendar",mURL.url());
+  }
 }
 
 void ActionManager::readProperties(KConfig *config)
 {
+  bool isResourceCalendar(
+    config->readBoolEntry( "UseResourceCalendar", true ) );
   QString calendarUrl = config->readPathEntry("Calendar");
-  if (!calendarUrl.isEmpty()) {
+
+  if (!isResourceCalendar && !calendarUrl.isEmpty()) {
     KURL u(calendarUrl);
     openURL(u);
-    KConfig *config = KOGlobals::config();
+    // Active calendars are no longer of any use, use ResourceCalendar instead
+/*    KConfig *config = KOGlobals::config();
     config->setGroup("General");
     QString active = config->readPathEntry("Active Calendar");
-    if (active == calendarUrl) setActive(true);
+    if (active == calendarUrl) setActive(true);*/
+  } else {
+    // TODO: Initialize a ResourceCalendar here
   }
 }


Comment 8 Reinhold Kainhofer 2003-08-07 19:43:56 UTC
*** Bug 59592 has been marked as a duplicate of this bug. ***
Comment 9 Reinhold Kainhofer 2003-08-26 19:47:34 UTC
Subject: kdepim/korganizer

CVS commit by kainhofe: 

This works around a session management problem with unique applications. Now the correct config will be used for the restoration.

What remains to be done is to restructure the KOrganizer constructor so that the decision whether to load a calendar file or the resource calendar is delayed until session restoration is done.

CCMAIL: 49356@bugs.kde.org, schumacher@kde.org


  M +5 -0      main.cpp   1.88


--- kdepim/korganizer/main.cpp  #1.87:1.88
@@ -90,4 +90,9 @@ int main (int argc, char **argv)
   KGlobal::locale()->insertCatalogue("libkcal");
   KGlobal::locale()->insertCatalogue("libkdepim");
+  // This is a workaround for a session management problem with KUniqueApplication
+  // The session ID gets reset before the restoration is called. This line makes
+  // sure that the config object is created right away  (with the correct config
+  // file name). Thanks to Lubos Lunak.
+  app.sessionConfig();
 
 //  kdDebug(5850) << "app.exec" << endl;


Comment 10 Cornelius Schumacher 2003-10-01 15:11:02 UTC
Subject: kdepim/korganizer [POSSIBLY UNSAFE]

CVS commit by cschumac: 

Fix session management by moving creation of the Calendar object from the
main window constructor to a separate function and calling this function
at the right places.

This fixes the most-hated (according to bugzilla) bug of KOrganizer.

CCMAIL: 49356-done@bugs.kde.org


  M +6 -1      actionmanager.cpp   1.35
  M +6 -6      kdatenavigator.cpp   1.30
  M +4 -2      koapp.cpp   1.73
  M +25 -15    korganizer.cpp   1.167
  M +3 -1      korganizer.h   1.68
  M +4 -1      interfaces/korganizer/mainwindow.h   1.9 [POSSIBLY UNSAFE: qDebug]



Comment 11 qaz 2004-09-15 00:21:05 UTC
it was fixed for a while but this bug returned in 3.3.0