NetAccess::statInternal and showing job progress

[David Faure]

On Tuesday 20 July 2010, Aaron J. Seigo wrote:
> On July 20, 2010, you wrote:
> > On Friday 16 July 2010, Aaron J. Seigo wrote:
> > > is there any pressing reason to show the progress info for stat/exist
> > > checks on remote files? i'd like to commit this and backport if there
> > > is consensus.
> > 
> > I object. This is very useful for slow (or even hanging) connections.
> 
> for file transfers, i agree. but for stats and existence checking, what's
> the use there? other than for debugging, which i really don't think is a
> good excuse for showing such things to the user every single time, i can't
> see the benefit to sending job notifications about checking for file
> details.
>
> stats and existence checking are almost never something the user is
> actively triggering (from their POV), and so the desktop starts sounding
> very "chatty" telling them about all kinds of internal details of things
> they haven't triggered (again, from their POV) and which they really don't
> care about.

Again, if it takes <1s, then yes, I agree that they don't need to care.
But if it takes 10 minutes because the server isn't responding, and meanwhile 
(without any kind of progress info) they don't know if the image got saved or 
not, then this would be a very severe bug, leading to data loss, potentially
(you think a file exists, and it does not).

> moreover, if an app really needs to beware of slow connections and user
> feedback as a result, they shouldn't be using NetAccess.

Well, if it was up to me, I would kill NetAccess and job->exec(), but that 
doesn't really solve this issue, does it?
 
> > It is not useful for fast connections, but the fix for that is to only
> > show notifications for jobs that last more than 0.5 second.
> 
> which is what nearly all of my ssh accounts take on first connect (and
> sometimes even on subsequent connects).

I'm okay with making it 1 second. But this isn't the main issue here.
The main issue is that the old dialogs disappeared once done, so a job that 
would last 600ms didn't bother the user for more than 100ms.
Now, on the other hand, because the plasma notification thing keeps a log of 
past jobs, the notifications for the small jobs annoy the user for a much 
longer timer. This is the issue that needs fixing imho. That window should 
expire stat jobs as soon as they're done, because, as you say, they were not 
directly initiated by the user, in contrast to e.g. downloads. But still, 
while the job is happening, the notification should appear.

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