Community
Participate
Working Groups
1. make some changes in java file 2. compare with head 3. invoke quick fix (in my case it was add nonlns tag) 4. regular java editor is activated (or opened).
(In reply to comment #0) > 4. regular java editor is activated (or opened). From what Dani has explained to me this is by design. When applying a quick fix in Compare Editor a regular Java editor will activated. However, when a Java editor is not open for a participant you're applying a quick fix in Compare Editor the focus will stay in the current editor part, ie Compare Editor. Krzysztof, please let us know if you see the same thing and what are you feelings about it.
>> 4. regular java editor is activated (or opened). >From what Dani has explained to me this is by design. Nope. What should happen is that we (re-)use the compare editor as long as it is active (see Ctrl+O for example).
Created attachment 126472 [details] Patch v01 A fix proposition based on the work Dani did in EditorUtility for the ctrl+o issue[1]. Not sure if we need to check if the cu is primary in this case (commented out). Dani what do you think about the patch, is it a step in the right direction? [1] bug 259408
Created attachment 126473 [details] mylyn/context/zip
(In reply to comment #2) > >> 4. regular java editor is activated (or opened). > >From what Dani has explained to me this is by design. > Nope. What should happen is that we (re-)use the compare editor as long as it is > active (see Ctrl+O for example). Sorry for twisting your words Dani, I must have misunderstood you.
>4. regular java editor is activated (or opened). This step is not fully true: only if the Java (or any other) editor is already open it will activate it instead of staying in the compare editor. >Dani what do you think about the patch, is it a step in the right direction? The fix should go into EditorUtility.isOpenInEditor(Object).
Created attachment 126711 [details] Patch v02 Another approach here could be extending CompareEditor with its own editor matching strategy. This would work for JDT, but it would also bring the Compare Editor to top for other calls within Workbench. I'm afraid this might more than we actually need, ie this might be unexpected behavior change. Dani what do you think? Should I limit changes to JDT's EditorUtility only?
> Dani what do you think? Should I limit changes to JDT's EditorUtility only? Yes, I think so.
Created attachment 126723 [details] Patch v03 How about this? Third time lucky?
The patch is good Tomasz. I renamed getEditor to findEditor and added Javadoc. Fixed in HEAD. Available in builds > N20090225-2000.
