A Qt replacement for KGlobal::ref and deref

[Aaron J. Seigo]

On Thursday, February 10, 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?
> 
> > > 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.
> 
> > > 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. So today any Qt
> application requires a window to display its progress. Therefore, the API
> for refcounting isn't needed.

that is easily provably wrong: KDE apps are also Qt apps, they don't require a 
window to display its progress and therefore refcounting is needed. i can 
trivially write a Qt app that uses the notification dbus service and end up in 
the same place.

now look at it from the other side: applications which don't require this 
feature don't need to touch the refcount, and for those Qt apps the world 
remains the same.

and of course, by your same reasoning then setQuitOnLastWindowClose shouldn't 
exist either.

you're tryng to make Qt into a straightjacket that fights against some very 
real use cases. what's really unfortunate is that those use cases represent a 
much more modern, multi-process view of the world than "all my UI is running 
this my app".

> > 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.

that's obviously up to the application, not Qt alone.

> So the way I see it, ref/unref is just a way to increase and decrease the
> number of windows this process has when the window is actually
> out-of-process. Abuse of that will lead to bad usability.

shall i list all the things that are easily abused in Qt for bad usability?

an app-global reference count allows the application to handle this very real 
use case; without it, the use case is not feasible. it's not Qt's job to 
prevent developers from shooting themselves in the foot with features that are 
otherwise needed to get a certain task done.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110213/7212296b/attachment.sig>