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.
I think I just noticed this recently, so may be related to running tasklist/pmd. Anyway - current dev build, currently published tasklist modules from AU. When I have a typical messy source file with a subnode full of Javadoc and PMD errors, after making any changes the document is usually reparsed immediately. (Sometimes it doesn't get reparsed until you make another change and then undo it, but that is for a different bug report.) I would expect that the only visible change in the task list Suggestions window would be the possible addition or removal of some items affected by my change (e.g. a correction), adjusting the selection if the selected task had been removed. Instead, all of the tasks are slurped out of the window in sequence (I can watch them go - slower the more there are, it seems), and then reinserted. The state of the GUI - expanded nodes and selection - is quite lost. Sometimes the different suggestion providers seem to run at different rates, or a reparse will show some ridiculous contents temporarily, then quickly remove them and replace them with the correct contents. I am not sure exactly what is wrong but it seems there is no coordination by the suggestions manager of the progress of each of the providers. I want the reparse to be invisible except when the list of suggestions available has completed and stabilized and includes some new or removed items - in which case just those items should be added to or removed from the GUI, leaving any expanded category nodes and node selections as intact as possible. (By the way it would be nice to have an option to never show category nodes, and always list all the suggestions in a straight list - the category nodes generally annoy me as a keyboard user. Grouping items by category is fine, but the category nodes don't interact well w/ F12 & S-F12, I think.)
F12 navigation spawned as issue 37068.
Typical rescan() pattern reads: manager.register(TYPE, newTasks, showingTasks, request); All providers need to merge tasks instead of replacing if possible. It depends on possibility to maintain suggestion identity.
Merging is enabled by existence of netbeans.todo.merge property. It causes ugly ordering problems because natural order cannot be retained properly using current register/addRemove() method.
I removed rescan() method from SPI. Providers are not able to merge anymore. On the other hand framework (SuggestionBroker) swaps found suggestions in atomic operation. Observable bug is that selection (highlighted suggestion) does not survive refresh (but F12 navigation continues from right point).
The claim that F12 navigation continues after refresh is invalid. It's doeable to make it work if we remeber extra planned next/previous task and we can locate these in new list.
It does not work at all for Todo window in autohide mode. F12 action perfomer looks for open topcomponent and changes its state (selected nodes). Importantly once topcomcoment gets hidden it unregisters F12 action perfomer. In the other words F12 functionality is bound to Todo window visibility. Autohide mode must be disabled by F12 action perfomer to avoid it. I do not see any API how to arrange it. Milos how can I manage it.
Milos mentioned friend "isSliding" client property. I could check sliding status and disable action for sliding views. However for proper solution I need Sliding API. Establishing Sliding API dependecy issue #45927.
FWIW I totally disagree with the proposed solution in #45927; this is just adding a gratuitous dependency on impl details of the window system to solve an unrelated problem. The root problem is that your action's enablement is dependent on visibility of the TopComponent, and that is wrong. F12 & S-F12 need to be fixed to behave differently - we know this is necessary for many other reasons anyway - and if implemented correctly, your binding of F12 would continue to work fine after the ToDo window was hidden... which is what is actually wanted.
My original request on F12 & S-F12 enhancement (issue #40185) did not attract code maintainer. Anyway I'm not sure if I can invent better action enablement logic without depending on Todos window visibility.
Well stick with #40185 please. We didn't get to it for D, but we're not providing a sliding windows API for D either. Better action enablement logic would probably be based on having the real action (global KB and menu binding) track open TopComponent's whose ActionMap's bind a well-known key to a performer, and delegate to the binding of the last such TC to be focussed. Or something along those lines. In any event, this would work with or without sliding mode since it does not require the TC to be visible at the time its binding is processed. The same logic could of course be used for Output Window hyperlinks, Search window hits, Where Used usages, etc.
For promo-D there is a workaround checking "isSliding" client property avoiding focus movement if TRUE. Selected suggestion visual indication is lost on suggestion fix but next navigation target can be restored from remembered candidate. TaskListView.java new revision: 1.112