On Sunday 05 February 2006 11:40, David Faure wrote:
> 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.


Yes, this part is clear.
>
> 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.


But sometimes all you want to really do is to have a repainted GUI while
doing a KIO transfer, but you don't care about other issues, like user
input. In such cases usage of async KIO is a little bit overkill, but
using NetAccess causes problems. I recently saw two examples of this:
1) K3B "hanging" random times while files were added to a DVD project.
The cause was NetAccess and somehow the event loop started by it was
not exited.
2) Quanta loads on demand some data from disk to prevent excessive
memory usage. As I used all over Quanta generic KIO aware code, in this
case I used tests such as "list" or "exist". The result was random
hangup while loading the data. And in this case I don't care about
those seconds it takes to load the data as anyway the user cannot do
anything without that data.

A safe NetAccess would be nice to have in this case.

For me in the first case I rewrote the code to reduce the number of
NetAccess calls to make safer and in the second case the solution was
to not use KIO at all, as thankfully I know that the data is local.

If needed, I can research both cases and give you the exact example when
things go wrong.

Andras

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