#2 UI Blocks on keyring load

[Mark Brown]

When talking to GPG (for example, to list all the
keys for the key management view) the program blocks
on the client program, locking the user interface and
preventing redraws. This would be fine if key
operations were always fast but the reverse is
frequently the case. Large keyrings can take quite
some time to process, particularly on slow machines.
Newer versions of GnuPG (current at time of writing
is 1.0.6) are reported to be very much faster but
there is a certain amount of processing that is
unavoidable.

The program should continue to respond interactively
while performing keyring operations. Hopefully it
should also be able to give some kind of feedback on
progress while waiting.

[Christopher Donald Wiegand]

Logged In: YES
user_id=9059

Threads are .... somewhat tricky, especially under C. I'll
take it into consideration for 2.0. The java version should
certainly be able to do that, when I get it ready for
public consumption. The C threads, however, aren't terribly
portable.

Even if the threads are implemented, you can only do one
keyring activity at a time, because the encryption program
shouldn't be loading the keyring while a user tries to, for
example, sign a key. That would be a Bad Thing. I'll keep
this in the list to remind me to look at threads, even if
only for keeping the UI up to date and locking the whole
window.

[Mark Brown]

Logged In: YES
user_id=160379

For something like this you can always fork a new process rather
than starting a thread. Neither is hugely involved.

Even if the encryption program is very fast you've still got to worry
about the possiblity that the system is slow or the keyring is very
large. The problem isn't so much that you can't initiate further
operations as that the program is locked so hard it can't do things
like respond to X redraw requests - it's not the waiting, it's the not
being able to tell if the program is alive at all.

I'll give you some timings later to show the extent of the problem.