Community
Participate
Working Groups
I had a project that was missing an external reference and therefore had many compile errors about classes that didn't exsist. I opened up the java build properties for that project and added the missing classes, and when the project was recopiling I could watch as each error was removed from the task list. It was slow enough so that I could read each one before it was removed.
Moving to platform since they provide task list.
I'm not sure what the issue is here. Is the task list not removing the errors at the same rate that the errors are being corrected in the build? If the problem is that errors are being incrementally removed while the build is happening, it is not the responsiblity of the taskview. taskview gets its markerdeltas from core as it chooses to send them. perhaps core should aggregate changes somehow?
I guess that the description I gave was not clear enough. The major problem was that the process was too slow. I highlighted the fact that the items could be seen to be removed one at a time because it seemed like the reason that the compile was slow was because it was waiting for the UI to update. Maybe I'm wrong with respect to the cause of the problem, but rebuilding when the rebuild removed many errors is horrible slow on linux-gtk
This may have been caused by a large number of small marker deltas or by a bottleneck in the GTK widgetry when removing a large number of markers while redraw is enabled. In either case, this is probably fixed by the patch to bug 44443. Please confirm that this is fixed as of I20031209. I am currently unable to reproduce it.
Awaiting replicatable case
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
