This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Asynchronous Look Wrapper | ||
---|---|---|---|
Product: | contrib | Reporter: | Jaroslav Tulach <jtulach> |
Component: | Looks | Assignee: | Petr Hrebejk <phrebejk> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | jglick |
Priority: | P3 | Keywords: | API, THREAD |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 35833 |
Description
Jaroslav Tulach
2003-03-25 15:15:24 UTC
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 |