On Sunday 05 February 2006 07:57, Mantia Andras wrote:
> On Saturday 04 February 2006 21:38, Joris Guisson wrote:
> > These function calls are wrappers around KIO::NetAccess calls :
> > bt:elete(dest,true);
> > bt::CopyFile(target,dest,true);
> >
> > I have seen this before and this only happens when KIO::NetAccess is
> > involved. I think nested KIO::NetAccess calls are the problem, and
> > that GUI events get delivered to the wrong event loop (that is
> > assuming that the KIO::NetAccess call starts it own event loop, which
> > seems to me is the way to make asynchronous KIO::Job's synchronous,
> > correct me if I'm wrong here)

> Yes, nested NetAccess calls or calling processEvents() when using
> NetAccess is just asking for trouble. If you are sure you don't need
> remote functionality, don't use NetAccess, or if you need in such
> nested cases use the asynchronous KIO jobs.
> BTW, this is very a unfortunate situation as NetAccess is very
> convenient and enough in many cases. I hope that with Qt4 this problem
> will disappear as I read we don't need the ugly enter_loop/exit_loop
> hack anymore.

With Qt4 the solution is a bit cleaner but still: handling user event while being
in the NetAccess call is a no-no. Too dangerous. The user could close the window
where this code is running, etc.

Think of NetAccess as a modal dialog. It blocks the control flow in your program,
doesn't prevent repainting, but it DOES prevent clicking on other parts of the
application, and that's on purpose.
So if you do want your application to be useable while a KIO transfer happens,
use the KIO jobs, they were made async for this reason in the first place.

David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<