Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 111571

Summary:	[Markers] Applying multiple quick fixes should allow single application
Product:	[Eclipse Project] Platform	Reporter:	Martin Aeschlimann <martinae>
Component:	UI	Assignee:	Tod Creasey <Tod_Creasey>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	gunnar
Version:	3.2
Target Milestone:	3.2 M3
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Martin Aeschlimann

2005-10-05 04:24:32 EDT

20051005

In the problems view, when you select multiple problems and invoke quick fix,
you get a dialog per problem.
So if you want to fix the 100 missing //non-nls tags, you will click 100 times.

It would be better to have a proposal, 'fix all'. Such a proposal would have to
come form the contributer of the quick fix. So a suggested solution is to extend
the extension point IMarkerResolutionGenerator with a new API
IMarkerResolution[] getResolutions(IMarker[] marker); so that an extension has a
chance to offer a 'fix' all.

UI-wise the user would have to choose between using the fix-all or the single
steping through the fixes.

Comment 1 Tod Creasey

2005-10-11 09:41:55 EDT

I now group these by matching message in the wizard.

Comment 2 Martin Aeschlimann

2005-10-11 09:52:29 EDT

What does that mean? In which build?

Comment 3 Tod Creasey

2005-10-11 10:08:42 EDT

build > 20051011. The only matching criterea I have to use currently is the
label of the IMarkerResolutions so I am using the label to group

Comment 4 Martin Aeschlimann

2005-10-11 10:35:39 EDT

The problem is that a quick fix for multiple problems isn't always the same as
fixing each problem one by one.

E.g. 'fixing' a problem by adding @SuppressWarnings: Assume there's a warning to
suppress in every method of a compilation unit. You wouldn't fix this by adding
an annotation to each method, but to the whole type.

Another example is that a fix for the one marker makes the fixes for all other
markers unecessary.

That's why the contributor needs somthing like a 'global' view  and should be
able to provide a fix that 'does it all'.

Comment 5 Tod Creasey

2005-10-11 10:44:50 EDT

I reprocess before I apply each page. This means that sometimes you will get a
message that no changes are available or that the selected change is now obsolete.

I didn't want to force implementors of the resolutions to re-implement or to not
support grouping of markers (i.e. thos bug) so this made the most sense as a
compromise.

Comment 6 Martin Aeschlimann

2005-10-11 10:54:39 EDT

I was suggesting an extension of the IMarkerResolutionGenerator to allow these
global fixes and nobody would be forced to change their existing fixes.

Comment 7 Tod Creasey

2005-10-11 11:02:52 EDT

So are you suggesting that I remove my current implementation and then only add
multiple marker support for those resolutions that support it?

There is a lot to be said for this as the current implementation has some
strange behaviour but I am afraid that no-one would do it because of time
constraints.

Comment 8 Martin Aeschlimann

2005-10-11 11:30:35 EDT

I wouldn't remove you implementation but let the user to choose between proposed
global proposals or to go through proposals step by step.

Comment 9 Tod Creasey

2005-11-01 10:11:27 EST

Verified in 20051101