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>|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:|
Description Jaroslav Tulach 2003-03-25 15:15:24 UTC
Imagine: Look Looks.asynchronous (Look look, long mask); would create a delegator to the original look that for all methods enumerated in mask replans the execution to RequestProcessor and meanwhile returns value like "Computing..." Would be very handy for easy responsivness tuning.
Comment 1 Jesse Glick 2003-08-25 18:11:42 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).
Comment 2 Petr Hrebejk 2003-08-26 09:36:52 UTC
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.
Comment 3 Jesse Glick 2003-08-26 17:39:30 UTC
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.
Comment 4 _ tboudreau 2004-01-06 17:07:52 UTC
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.
Comment 5 Petr Hrebejk 2004-07-20 14:58:28 UTC
Changing target milestone on all Looks issues to future
Comment 6 Petr Hrebejk 2007-01-09 15:10:22 UTC