Bugzilla – Full Text Bug Listing
| Summary: | [Progress] KEEPONE doesn't remove duplicate jobs from the progress view | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jean-Michel Lemieux <jean-michel_lemieux> | ||||
| Component: | UI | Assignee: | Andre Weinand <andre_weinand> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | douglas.pollock, marcus.lindblom, Michael.Valenta, michaelvanmeekeren, n.a.edgar, Tod_Creasey | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | 3.0 RC4 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Jean-Michel Lemieux
The specification for IProgressConstants#KEEPONE is incorrect: a job with the KEEPONE property
removes other jobs of the same family on start. Without this behavior there would be two and not one
job in the progress view.
I verified this behavior with the JobExample and it worked fine for me.
However, this behavior is problematic if you cannot set the KEEPONE property early (before starting the
job). In this case other jobs of the family aren't removed because the existence of the property is only
checked once at start.
What do you suggest?
fix the doc and keep the behavior (if you are able to set KEEPONE early)
or
change the behavior to test the KEEPONE property on start and finish
(and adapt the doc too)
+1 for option 2. We set KEEPONE==true if the job is run in the background. But we can't tell if the job is run in the background when the job is started or created. Instead, at the end of the job we set the KEEPONE==!IN_DIALOG. I don't mind having two jobs at once in some cases, it is better than the progress view accumulating many of them. I'm sorry I didn't catch this earlier, but such is life :) So for RC3 I recommend to add an additional check for the KEEPONE property to the remove case
and update the doc of IProgressConstants#KEEPONE to the following:
"That is, whenever a Job with the KEEPONE property starts and finishes, all other
kept Jobs of the same family are removed first."
Without this change, doc and implementation are out of sync and jobs will add up if clients set the
KEEPONE property too late.
Created attachment 12464 [details]
patch for org.eclipse.ui.workbench
Again, +1 and I've reviewed and actually tested the change. *** Bug 67750 has been marked as a duplicate of this bug. *** *** Bug 66715 has been marked as a duplicate of this bug. *** *** Bug 68020 has been marked as a duplicate of this bug. *** Patch approved +1 Can someone give me good steps to replicate this before we release it please? Jean-Michel? Use Case 1: - disable 'always run in backgorund' preference. - run a Team > Synchronize with Repository - Progress dialog appears - don't touch it and let the operation complete - When the operation is done an entry will be left in the progress view Use Case 2: - Schedule a team sychronize (e.g. view the synchronize view menu) for every one minute. - Let a couple of scheduled synchronizations occur and notice that they will accumulate in the progress view. - You won't be able to remove them with the 'XX' button. They stay in the view. Use Case 3: - Run Team > Synchronize and in the progress dialog select "run in background". - The finished synchronize should stay in the progress view - Run another and run in background - Only one synchronize should be in the progress at the end. The synchronize job sets the KEEPONE property in the following way: - when job is started KEEPONE = ! IN_DIALOG - when job ends (e.g. at the end of the run() method) KEEPONE = ! IN_DIALOG I can't get any of JMs use cases to work. JM could you recheck this patch please? Sorry - forget that. I was looking at the wrong workbench. let me retry. i have verified the current state however. This fixes case 2 but not case 1 or 3 - the main issue is that these finished jobs do not leave the view which I think is actually Bug 62995. If this patch is stil acceptable to Jean-Michel I will release it. Released the patch. I will leave this open until we are sure that the other two cases are really Bug 62995 *** Bug 68274 has been marked as a duplicate of this bug. *** Marking as fixed as we have verified that the other cases are Bug 62995 Verified in 20040623-1600 |