A Qt replacement for KGlobal::ref and deref

David Faure faure at kde.org
Mon Feb 14 10:03:42 GMT 2011

On Thursday 10 February 2011, Thiago Macieira wrote:
> Em quinta-feira, 10 de fevereiro de 2011, às 12:45:58, David Faure escreveu:
> > > 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
> I don't dispute that. I'm simply asking that there is some kind of feedback
> *while* that is happening.
> Imagine you send an email, close the kmail, and now you want to suspend
> your computer. How do I know that the email sending has finished?

OK, there should be a job notification. However that is done in another process 
for better integration with the desktop.

> > > 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.
> Only if it's down when you start the job. If the connection goes down while
> the transfer is in progress, there's at least 30 seconds timeout -- and
> that's if there's a timeout at all.

OK, solved by the notification too.

> > > 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.
> Right, but there's no API for doing that from Qt. 

Well, there's QtDBus. Remember, you wrote it :-)

> > So today any Qt application requires a window to display its progress. 

See Cornelius, why we can't move kdelibs functionality to Qt? Because the Qt 
developers consider that Qt is only meant for standalone apps, not for an 
integrated desktop :(

> > 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.
> Systray icon, yes. Jobs with visual feedback (even if out-of-process), yes.
> Jobs with no visual feedback, no.

Great, then let's add an API in Qt for letting running jobs increase/decrease 
the refcount, and let's document it as "don't use this if you are not showing 
any visual feedback".

David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

More information about the kde-core-devel mailing list