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

List:       kfm-devel
Subject:    Re: kio::netaccess and imagepreview
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-06-10 20:32:38
[Download RAW message or body]

On Sat, 10 Jun 2000, David Faure wrote:
> On Sat, Jun 10, 2000 at 03:23:09PM +0200, Simon Hausmann wrote:
> > thumbnails. The backtrace is always different, but in the end it always
> > looks like this:
> >
> > - the mainwindow receives a close event and destroys all views, etc.
> > - no more toplevel windows exist -> lastWindowClosed is emitted which is
> >   connected to qapp->quit(), which sets app_exit_loop to true
> > - now we return back to the event loop
> > - ah, the event loop is finished, because app_exit_loop is true
> > - we leave enter_loop() and return
> > - oops! we were in a enter_loop() call in KIO::NetAccess! Now we return
> >   before the job finished and after everything has been destructed
> >   --> boom

> So the question is: is there a way to know that there is still a network
> transparent operation happening...

Yes, this is exactly the problem I filed a bugreport for the other day.. if 
you do a saveAs in konqueror and then close the window, the "save-as" action 
gets aborted. 

What about registering network operations to kapp and/or ktmainwindow 
(refcounting)?

> Hmm, there is QApplication::loopLevel(). If it's more than 1, then we have
> some NetAccess operation going on. Does that help ? Can you check its value
> in both cases (with or without an operation going on) ? Hmmm.
[And]
> Another idea. Maybe we can set a static flag (bool) in KFileItem which
> says: currently doing an image preview operation. We set it to true
> at the beginning of the method and to false at the end of the method.
> Well, maybe not static but in the related mainwindow, that would be better.
> Then in the queryClose of the mainwindow, we can kill the job (how to get
> its pointer?) or simply wait for it (?)...

That sound a bit like a hack to me. Basically you want a generic signal like 
"no active parts left". KTMainWindow::queryExit() is a signal like this but 
specific to "mainwindows", to handle this situation we need a more generic 
solution.

Note that a typical KDE application never actually should do something with 
queryExit() besides returning true. 

What about adding something like "ref()" and "deref()" to KApplication. When 
the ref-count decreases and becomes 0 or smaller we quit. Then it's just a 
matter of letting KTMainWindow do a ref() and ~KTMainWindow do a deref(), 
things like download then need to do their own ref() and deref().

Cheers,
Waldo
-- 
Make way, KDE/Linux is coming to a desktop near you!

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