Please don't work on this at the moment, as I would probably instead
require Look methods to be event-thread only (in which case this makes
no sense).

Don't worry. I'm not planing to work on it now.
Nut anyway even if all methods in looks will be AWT only (which would
be good I think) sometimes it may happen that some of the methods will
take long time. In this case I think the Look should return some temp.
value from the AWT method, then compute the proper value (in other
thred) and then fire change of the value (In AWT when necessary).
Support for such thing may not be bad.

However, I'll wait, till now anything like above was not required.

Agreed, there may be some use for a convenience support class which
would display a "Please wait..." node or similar while something was
being computed. If and when we need something like this, we can try to
create such a class. My main concern about the suggested

Look Looks.asynchronous(Look look, long mask);

was that methods in the delegate Look would be called from off AWT, so
if there is a general contract that Look methods are AWT-only, the
delegate Look would have to be custom-written for the occasion (it
would be illegal to pass an arbitrary Look as a delegate here, since
it might not be prepared to deal with multithreaded access). Partially
a documentation problem, I guess.

FWIW, Navigator will need something like this for handling, e.g.,
generating a children list containing all members of the selected
class or any ancestor classes - this currently has pretty severe
performance problems if done in the EQ.  Another possible case is a
Look which does something like return VCS versions.

I don't really care if it's Look that does it or not, but *somebody*
has to do this work in another thread, and the Look has to return
something reasonable while that's happening.

C.f. my suggestion (and Jesse's implementation) re parser queues.

Changing target milestone on all Looks issues to future

x