On Thursday 10 February 2011, Thiago Macieira wrote: > My argument against this solution is that when I tell the application to > Quit, I expect it to do it.
Sure, and KGlobal::ref/deref does not break that. But we're not talking about calls to qApp->quit here, we're talking about "closing the last mainwindow while there's still a download going on in the background -- or a systray icon -- or a mail being sent". > I certainly don't expect it to continue > running in the background until certain services finish running, in the > background. I can tell you, users definitely expect their download to finish, their mail to be sent [this has hit my wife a few times in kmail!]. And if a systray icon increases the refcount it's also a way to easily implement "only quit the process once there's no more mainwindow -and- no more systray icon". > There are two problems with this: imagine the case of trying > to upload my file to a server while my connection is down. First of all, > the application continues running after I told it to quit. Second, I don't > see the fact that there's an important upload running. I don't understand this example. If your connection is down, the job will fail quickly and the app will exit fast. > The correct way to solve this problem is to show another window indicating > that it is doing something and tell me what. We solve both problems at > once: there is a window open, so it's not yet a quit from > QCoreApplication's sense, and the user gets feedback. You assume the progress window is in-process, but this leads to ugly unorganized popups all the time so in KDE nowadays we show progress in kuiserver / plasma instead. So you can't use the window as a "don't quit now refcounting", you need the job for that. > > Thiago did also offer the solution of a separate service providing the > > refcounted quit functionality, but the problem with that is that all > > libraries and applications need to use the same ref/deref code otherwise > > it won't work. If I create a separate library with a service providing > > that functionality it wouldn't help because there would be no guarantee > > that all apps and libraries would use it. The solution would need to be > > in Qt. It works in KDE of course because all KDE libraries and > > applications use KGlobal::ref and deref, which perpetuates our walled > > garden. > > They already do. The KGlobal::ref()/deref() function is already separate > and all libraries need to use it. But KMainWindow, KJob and KSystemTrayIcon use it, so for the application developer, it's all transparent. If this is added to Qt, then QMainWindow and QSystemTrayIcon should use it, otherwise people will just forget. I don't understand the problem. Instead of just counting open windows, you also count other things which ask to be counted - systray icon and jobs. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).