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.
Now, when we have a lot of problems with scanning of projects/classpath and with performance of this action (especially a long time for first scan and *sometimes* never ending scan of classpaths, ......) I would like to see possibility *cancel / stop / kill * scanning , if user see that it takes longer time than he/she want spend -> he/she can kill scan and do another , more usefull work.....
Seems like a request for a new feature. We can consider it for the next release.
Martin, ok , for now I agree it's enhancement, but if you don't fix issues related to not finished scan, this will be bugfix ;) BTW: this is P1 / usability problem - user comes to the state from where he/she can't go out for long long time !
I disagree it is a P1. You should not take into account that there is a bug that causes that the dialog never goes away - that's a separate issue and I agree that that issue is P1. In this case I don't believe it is P1 - it was not identified as P1 in usability study and by UI team. The window is now implemented according to the agreement with our UI engineer. Are there guidelines saying how long time an uncancelable action can take? What should be the result of cancelling the scanning? Are you going to propose to put a cancel button on the splashscreen, which can also take long time on a slow machine?
Martin, klidek .... ;) If HIE desided ... ok .... -------------- > You should not take into account that there is > a bug that causes that the dialog never goes away - that's a separate > issue and I agree that that issue is P1. Really, and what about *Re-scan Project classpath* action in Tools menu ??????? If you will use the same pattern, what does this action in the IDE ???? -------------- I think .... for actions with long run time, is the best solution progress bar with Cancel button.... especially for actions that user doesn't invoke explicitely (scanning as it's implemented by our refactoring invokes scan implicitly ) !!! My last two xx : ============ next section is about designing dialogs with Progress indication from page : http://www-106.ibm.com/developerworks/web/library/us-progind/?dwzone=web#Externals4 =========== .... a fairly comprehensive list of button labels that can be found on progress indication displays: * Common actions: Stop, Cancel .... Cancel means rollback or undo while Stop means proceed no further. .... --------------- something similar can be found in the Jeff Johnson's book GUI Bloopers (almanach for developers of UI responsiveness SW) BTW: Don't decrease priority, if you disagree reassigne to HIE.
My point of view: There should exist some way to cancel long scanning (more then half of minute is really too much) or move it into the background. But I would like to ask the following: 1.When user decides to cancel this dialog, he won't be able to use Code completion and Refactoring actions (and any other actions?) right? 2.When user moves this scanning into the background, the IDE will be too slow anyway for normal work, right ? Then...It look's like, that with current implementation we haven't any other chance, then to leave this dialog as modal. I think, that ideal solution is to offer to user a chance to skip this dialog, move scanning into the background (without using all capacity of CPU ;) and then show small progress indication in the global status line in the future. User will want to use some feature depending on that scanning in the background of course...Then there should exist some implementation and UI "hacks". Yes this solution is more complicated then modal scanning, but user will appreciate it definitely :) BTW: Re-scan Project classpath action in Tools menu shouldn't exist when Refactoring will be stabilized enough in the future. This menu item indicates bad implementation or design.
This is a defect. Please read my post on nbdev and reply there. And P1 is correct priority - it is like deadlock, data lost and everything! Even after restart I had to watch bunch of exceptions from several modules. The IDE was dead here for sure.
Changing back to enhancement - there was a bug (issue 45077) that caused what David describes. The bug was fixed today.
I'm voting for this issue, but I'd like to hint at different possible solutions: - having the initial scan disabled by a per user / per project / per package property, so that its not starting in the first place (might be easier, as it doesn't pose the problem of 'interupted' scans. - incremental scanning + caching, which means to watch for changes on the classpath. While this is toughter to implement, it would save us to rescan such things like rt.jar, jsse.jar, xslt.jar ... all that things you are not constantly changing in your project...
To thsch: please see issue 47415
*** Issue 43909 has been marked as a duplicate of this issue. ***
Javacore module was replaced by Retouche infrastructure. This bug is not valid in trunk any more.
v/c
Reorganization of java component