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 lea=
ve
> 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 y=
ou
> 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 tw=
o
> cases here, either the libs are broken or our app is broken. Since I al=
ways
> thought that 'quit' means 'quit', and not 'close all windows' I wrote t=
his
> patch. Your remark on background KIO transfers makes sense though, in w=
hich
> 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 invisibl=
e
> 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 acc=
pet=20
the event, like you did. However, there's another "window" (a widget in=20
fact): the one in the system tray you have to create to get the icon in t=
he=20
tray. This one is still closed by closeAllWindows() and explicitely kills=
 all=20
the note windows in its destructor.

Now I don't use KSystemTray in KNotes ;-P because it doesen't use an acti=
on=20
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=20
talked about is the one of KSystemTray... So to get the same behaviour as=
 I=20
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 c=
lose=20
by hand even if closeEvent() is reimplemented and doesn't accept the even=
t?).=20
Not sure if this could break something.... ouch, yes, it will break the c=
ase=20
someone is deleting the KSystemTray because he just wants to remove the=20
system tray icon :(

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

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

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

--=20
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'
  =B0--web: http://www.kde.org/people/michaelb.html

KDE 3.0: Konquering the Desktops