This is a discussion on Re: GUI unresponsiveness - KDE ; 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 ...
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
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.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<