[PATCH] ksystemtray.cpp

[Michael Brade]

On Saturday 13 April 2002 13:09, Martijn Klingens wrote:
> On Saturday 13 April 2002 09:22, Simon Hausmann wrote:
> > I think it is a bad idea to call qApp->quit() from a library class,
> > because it unconditionally aborts the application, completely
> > disobeying KApplication's reference counting (which exists for the
> > very reason of preventing leaving the event loop in case there are
> > still background jobs like KIO tranfers) .
> >
> > What was wrong with closeAllWindows() ?
>
> Closing the main window in the case of a systray app should usually leave
> the app running in the tray. So essentially you'll override closeEvent() to
> hide the window instead of closing it and everybody's happy... unless you
> select 'quit' from the tray which now no longer quits and acts like a
> window close.
>
> And that's the problem we have with Kopete. I figured there could be two
> cases here, either the libs are broken or our app is broken. Since I always
> thought that 'quit' means 'quit', and not 'close all windows' I wrote this
> patch. Your remark on background KIO transfers makes sense though, in which
> case apparently Kopete is borked. I wonder what the solution is in that
> case, though. The only solution I see is to have an additional invisible
> main window, so the closing of the first doesn't trigger the quit yet. Ugly
> as well. Any better idea?
Hmm, in KNotes I just hide the note windows in closeEvent() and don't accpet 
the event, like you did. However, there's another "window" (a widget in 
fact): the one in the system tray you have to create to get the icon in the 
tray. This one is still closed by closeAllWindows() and explicitely kills all 
the note windows in its destructor.

Now I don't use KSystemTray in KNotes ;-P because it doesen't use an action 
for quit :( but implemented my own system tray code in KNotes.

So I guess this is different in kopete: the equivalent destructor to the one I 
talked about is the one of KSystemTray... So to get the same behaviour as I 
have it in KNotes we can simply add
    if ( parentWidget() )
        delete parentWidget();
to KSystemTray's destructor (is there another way we can force a window close 
by hand even if closeEvent() is reimplemented and doesn't accept the event?). 
Not sure if this could break something.... ouch, yes, it will break the case 
someone is deleting the KSystemTray because he just wants to remove the 
system tray icon :(

Hmm, so I can see only one other solution: reimplement KSystemTray's 
destructor yourself. Any better ideas?

BTW, that means I'm quite sure that Martijn's patch could break apps, 
especially those that inherit from KSystemTray and act like KNotes.

PS: why is the last line in ksystemtray.cpp 
   #include "kdockwindow.moc"
? This looks like a mistake....

-- 
Michael Brade;                 KDE Developer, Student of Computer Science
  |-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
  °--web: http://www.kde.org/people/michaelb.html

KDE 3.0: Konquering the Desktops