[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KDE shutdown does not wait till queryExit() returns true
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2006-02-23 18:10:14
Message-ID: 200602231910.14772.l.lunak () suse ! cz
[Download RAW message or body]

On Tuesday 21 February 2006 11:30, Sven Burmeister wrote:
> Hi!
>
> And first of all, thank you for taking the time to explain the matter to a
> beginner!
>
> Am Dienstag, 21. Februar 2006 10:42 schrieb Lubos Lunak:
> > > I read that it is not recommended to re-implement closeEvent() but
> > > rather queryClose und queryExit. Further the docs say that if one has
> > > serious things to do, one should connect aboutToQuit to queryExit.
> >
> >  Do they?
>
> They do:
> http://developer.kde.org/documentation/library/3.5-api/kdelibs-apidocs/kdeu
>i/html/classKMainWindow.html#b4 states to use shutDown(), the cvs-api-doc
> states to use aboutToQuit().

 I meant specifically the part about connecting aboutToQuit() to queryExit(). 
It says to connect aboutToQuit(), but not to queryExit().

>
> > > If it is expected behaviour, how can I make KDE wait on shutdown, if
> > > the application is only in the tray?
> >
> >  If you want to do something specific to a window, use queryClose() (or
> > closeEvent() for non-KMainWindow cases), and pay attention to
> > KApplication::sessionSaving() if you do something that could break
> > logout. If you want to do just a cleanup for the window, use a destructor
> > of course.
>
> I do that. Waiting for the app to finish its own shutdown-process works
> perfectly, if the window is open. As you explained, it does not, if the app
> is in tray only, simply because there is no window and hence not
> closeEvent() to wait for.

 I said you should use it only if you have something specific to a window. 
Since your case is apparently not related to a window, as you don't need to 
have a window, you shouldn't use this.

>
> Since the docs say something about "serious things", I thought that KDE
> would not only wait for closeEVent() to return true, but also for
> queryExit, yet that is obviously wrong.

 As I already said, the queryExit() logic is flawed. But if you meant the 
aboutToQuit/shutdown signals here, then ksmserver doesn't wait for these when 
shutting KDE down. There's no technical support for this in the session 
management spec and I guess it has never been needed before.

> >  And to answer your question, I can't actually do that because I don't
> > know what you need (you know, people, it'd be much simpler to help you
> > didn't just say what you think you need but also mentioned why you need
> > it).
>
> Sorry, I'll explain what I want to do. KVpnc handles my VPN connection, if
> I disconnect from the VPN, kopete has to go offline before the connection
> is actually disconnected as it would not be able to send the "going
> offline" to the IRC/ICQ etc.-servers afterwards.

 So the server otherwise would have to detect the client went away from the 
fact that it went away? Big deal ... like if I've never closed my icq without 
a clean shutdown.

> KVpnc executes a shell-script with a dcop-command to tell kopete to go
> offline and since that takes some time, a sleep of x seconds.

 Uhm, uhm ...

> After that 
> KVpnc disconnects, i.e. terminates vpnc and restores the old route and
> resolv.conf.
>
> If KDE shuts down before vpnc is disconnected, the resolv.conf and route
> will not be restored, so KDE shutdown should wait until the disconnecting
> has finished.

 But then you have exactly the same problem if e.g. something (X, your app) 
crashes, don't you? Moreover I think you're trying to solve a problem that 
you've complicated yourself - why don't you simply make your app quit without 
any sleeps or whatever, kopete will do its cleanup on its own (and it's 
supposed to handle the case of unclean cleanup anyway) and you just put a 
simple script in $KDEDIR/shutdown that'll do your cleanup? That way it'll be 
assured it runs at the end of the shutdown.

> >  If you want to do a cleanup at exit, use a dtor or aboutToQuit(). If you
> > want to display something like "shutting down KDE will cause XYZ", then
> > a) first consider if the user really needs to be told that, b) use
> > KSessionManaged::commitData().
>
> No user interaction or displaying, just disconnecting and waiting for it to
> finish before shutting down KDE. So, if I understood you correctly, I have
> to re-implement commitData() and put the disconnecting in there, because
> KDE waits for that one to finish, before telling all apps to exit?

 Uhm ... (checking the docs), not really. As I already said you shouldn't do 
any cleanups while saving, because you're not guaranteed it will be followed 
by a shutdown (you may e.g. begin a logout, your app does the cleanup, then 
open KWrite with unsaved file may give you the save/discard/cancel dialog, 
you find out there's still something you need to do, so you cancel the 
shutdown but you can't undo the cleanup).

> And commitData will also be called when a window is open on KDE-shutdown.

 KSessionManaged shouldn't have any relation to any window at all.

> > > KDE seems to only respect closeEvent(), yet that one seems to be not
> > > triggered when apps are only in tray.
> >
> >  Hmm, am I already boring to say again that hidding windows to the tray
> > is a broken concept?
>
> Is there no way to treat them as if they were minimised, but to another
> place than the taskbar?

 There is, it's just that part of the systray mess is that different people 
have different ideas on what exactly systray should be.

> Those get handled correctly, although they do not 
> have a visible window. Maybe just an ignorant thought by an beginner. ;)

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]