Version: (using KDE Devel) Installed from: Compiled sources I recently updated my CVS build of Kopete, and now I am having a hard time keeping it open. It appears to exit at times (1 or 2 times a day) when closing a chat window, however, it seems to be random when it happens. There is no crash error that is reported, so I think it's exiting, and it's not really a crash. This wasn't happening on a CVS build checked out on 1-21-04. Just since I checked it out on 2-19-04.
*** This bug has been marked as a duplicate of 73793 ***
... that's not the bug I thought it was ... Anyway, I'm half way through fixing this...
CVS commit by lilachaze: Sort out Kopete's KApp reference counting. Fixes #75805. [BACKPORT] CCMAIL: 75805-done@bugs.kde.org M +5 -0 kopete.cpp 1.170.2.1 M +6 -8 kopetewindow.cpp 1.170.2.1 M +7 -4 chatwindow/kopetechatwindow.cpp 1.62.2.7 M +11 -7 chatwindow/kopeteemailwindow.cpp 1.30.2.3 M +1 -1 chatwindow/kopeteemailwindow.h 1.6.2.3 --- kdenetwork/kopete/kopete/kopete.cpp #1.170:1.170.2.1 @@ -48,4 +48,9 @@ Kopete::Kopete() m_mainWindow = new KopeteWindow( 0, "mainWindow" ); + // KApplication sets the reference count to 1 on startup. KopetePluginManager has a + // reference to us once created, so create it and drop our own reference. + KopetePluginManager::self(); + deref(); + /* * FIXME: This is a workaround for a quite odd problem: --- kdenetwork/kopete/kopete/kopetewindow.cpp #1.170:1.170.2.1 @@ -425,5 +425,10 @@ void KopeteWindow::closeEvent( QCloseEve if( app->isShuttingDown() || !KopetePrefs::prefs()->showTray() || !isShown() ) { - KMainWindow::closeEvent( e ); + // DO NOT call base class's closeEvent - see comment in KopeteApplication constructor for reason + // Save settings if auto-save is enabled, and settings have changed + if ( settingsDirty() && autoSaveSettings() ) + saveAutoSaveSettings(); + + e->accept(); return; } @@ -435,11 +440,4 @@ void KopeteWindow::closeEvent( QCloseEve i18n( "Docking in System Tray" ), "hideOnCloseInfo" ); - // FIXME: Instead of ignoring the close event it's much better to have - // KopeteSystemTray ref() the KApplication object and deref it on - // quit. This way we can pass on the event to Qt unmodified instead. - // We may or may not need to remove the destructive close from the - // WFlags of the window though when doing this. Ideally the code - // should be able to handle the case where no main window exists, - // but I'm not 100% sure this is actually the case. - Martijn hide(); e->ignore(); --- kdenetwork/kopete/kopete/chatwindow/kopetechatwindow.cpp #1.62.2.6:1.62.2.7 @@ -1126,8 +1126,11 @@ void KopeteChatWindow::closeEvent( QClos if ( canClose ) { - // Call the parent class's closeEvent, which will accept() the event, - // but also make sure that we deref() KApplication if we're the last - // open window - KParts::MainWindow::closeEvent( e ); + // Save settings if auto-save is enabled, and settings have changed + if ( settingsDirty() && autoSaveSettings() ) + saveAutoSaveSettings(); + + e->accept(); + + // DO NOT call base class's closeEvent - see comment in KopeteApplication constructor for reason } else --- kdenetwork/kopete/kopete/chatwindow/kopeteemailwindow.cpp #1.30.2.2:1.30.2.3 @@ -330,4 +330,15 @@ bool KopeteEmailWindow::eventFilter( QOb } +void KopeteEmailWindow::closeEvent( QCloseEvent *e ) +{ + // DO NOT call base class's closeEvent - see comment in KopeteApplication constructor for reason + + // Save settings if auto-save is enabled, and settings have changed + if ( settingsDirty() && autoSaveSettings() ) + saveAutoSaveSettings(); + + e->accept(); +} + void KopeteEmailWindow::slotViewToolBar() { @@ -370,11 +381,4 @@ void KopeteEmailWindow::slotConfToolbar( - -bool KopeteEmailWindow::queryExit() -{ -// never quit kopete - return false; -} - void KopeteEmailWindow::slotSetFont() { --- kdenetwork/kopete/kopete/chatwindow/kopeteemailwindow.h #1.6.2.2:1.6.2.3 @@ -77,5 +77,5 @@ signals: protected: - virtual bool queryExit(); + virtual void closeEvent( QCloseEvent *e ); virtual void windowActivationChange( bool activated ); virtual bool eventFilter( QObject *o, QEvent *e );
is this checked into the HEAD as well?
Yes. Test away.
*** Bug 75964 has been marked as a duplicate of this bug. ***