CompareEditorInput setDirty difference between eclipse 3.2 and 3.3 [message #328960] |
Mon, 09 June 2008 11:57  |
Eclipse User |
|
|
|
Hi,
it seems that there was a change in the
CompareEditorInput.setDirty(Object,boolean) implementation from 3.2 to
3.3. As a result only the first node in the structured diff viewer is
"rendered" dirty (i.e. <Node>) after some text merge was done in the
lower pane. Every subsequent text merge on a different node does not
mark the node dirty. It seems that the code change only fires a property
change (which results in showing the nod dirty?) if the editor input
isn't dirty yet.
Does anyone know why this change was introduced and how I can further
show all dirty nodes dirty?
Thanks in advance,
Jan
|
|
|
Re: CompareEditorInput setDirty difference between eclipse 3.2 and 3.3 [message #328967 is a reply to message #328960] |
Mon, 09 June 2008 13:55   |
Eclipse User |
|
|
|
Jan,
There were changes made in that area in 3.3. However, I don't see the
relationship between the setDirty(Object, boolean) method and the nodes
you are referring to. The purpose of the setDirty method(s) on
CompareEditorInput is to track the dirty state of the editor and, as
such, only has two states (dirty and notdirty) and only fires events
when that state changes. It sounds like, in 3.2, the compare editor
input was firing additional events, even if the state didn't change and
the structured diff viewer you are referring to was relying on those
events to update its decoration.
Part of the work in 3.3 was to add support for the use of file buffers
(i.e. shared documents) to compare. With this support, both the
structured viewer and the merge viewer can use the same underlying
document and the structured viewer can update its state properly by
listening to changes to the document. This is mentioned in the ISV doc at
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/compare_structureviewer.htm
The last paragraph mentions the abstract StructureCreator superclass
which has built in support for shared documents.
Michael
Jan Mauersberger wrote:
> Hi,
> it seems that there was a change in the
> CompareEditorInput.setDirty(Object,boolean) implementation from 3.2 to
> 3.3. As a result only the first node in the structured diff viewer is
> "rendered" dirty (i.e. <Node>) after some text merge was done in the
> lower pane. Every subsequent text merge on a different node does not
> mark the node dirty. It seems that the code change only fires a property
> change (which results in showing the nod dirty?) if the editor input
> isn't dirty yet.
>
> Does anyone know why this change was introduced and how I can further
> show all dirty nodes dirty?
>
> Thanks in advance,
> Jan
|
|
|
Re: CompareEditorInput setDirty difference between eclipse 3.2 and 3.3 [message #329123 is a reply to message #328967] |
Fri, 13 June 2008 09:37   |
Eclipse User |
|
|
|
Michael, thanks for the detailed explanation.
> when that state changes. It sounds like, in 3.2, the compare editor
> input was firing additional events, even if the state didn't change and
> the structured diff viewer you are referring to was relying on those
> events to update its decoration.
It seems to be exactly that way. Unfortunately also the structured diff
viewer is not in my hand.
> Part of the work in 3.3 was to add support for the use of file buffers
> (i.e. shared documents) to compare. With this support, both the
> structured viewer and the merge viewer can use the same underlying
> document and the structured viewer can update its state properly by
> listening to changes to the document. This is mentioned in the ISV doc at
>
> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/compare_structureviewer.htm
I am going to read it - thanks for the hint.
Jan
|
|
|
Re: CompareEditorInput setDirty difference between eclipse 3.2 and 3.3 [message #331323 is a reply to message #328967] |
Mon, 01 September 2008 12:04   |
Eclipse User |
|
|
|
Michael,
> The last paragraph mentions the abstract StructureCreator superclass
> which has built in support for shared documents.
I am currently using the existing ResourceCompareInput class which does
not seem to support this new 3.3 features, doesn't it?
As far as I can see I would have to enhance the compare editor input to
be able to use it with a StructureCreator to be able to use a
StructureDiffViewer instead of a plain DiffTreeViewer, right?
I tried other way to somehow hook into the notification chain between
the change event from the document and the editor input. Seems to be
impossible because most stuff is either private or it's seems to be
difficult to get access to the relevant document/viewer.
Jan
|
|
|
Re: CompareEditorInput setDirty difference between eclipse 3.2 and 3.3 [message #331359 is a reply to message #331323] |
Wed, 03 September 2008 14:12   |
Eclipse User |
|
|
|
The ResourceCompareInput class is internal to the Compare framework.
It's use by other clients is not supported. The
SaveableCompareEdiorInput was introduced in 3.3 and has support for
shared documents.
Michael
Jan Mauersberger wrote:
> Michael,
>
>> The last paragraph mentions the abstract StructureCreator superclass
>> which has built in support for shared documents.
>
> I am currently using the existing ResourceCompareInput class which does
> not seem to support this new 3.3 features, doesn't it?
>
> As far as I can see I would have to enhance the compare editor input to
> be able to use it with a StructureCreator to be able to use a
> StructureDiffViewer instead of a plain DiffTreeViewer, right?
>
> I tried other way to somehow hook into the notification chain between
> the change event from the document and the editor input. Seems to be
> impossible because most stuff is either private or it's seems to be
> difficult to get access to the relevant document/viewer.
>
> Jan
|
|
|
Re: CompareEditorInput setDirty difference between eclipse 3.2 and 3.3 [message #332955 is a reply to message #331359] |
Mon, 17 November 2008 07:36   |
Eclipse User |
|
|
|
Michael,
thanks for the hints. However, I don't grasp how the
SaveableCompareEditorInput can be used the way the ResourceCompareInput
is working. It's furthermore abstract, located in the team plugin area
and the available implementations are mainly team oriented and do not
fit as the ResourceCompareInput does.
Why is the ResourceCompareInput class internal anyway? It's perfect to
directly compare two resources. As far as I can see it's only made
available at user interface level (compare actions). Any chance to use
it in code or any chance to have it available in future versions?
Jan
> The ResourceCompareInput class is internal to the Compare framework.
> It's use by other clients is not supported. The
> SaveableCompareEdiorInput was introduced in 3.3 and has support for
> shared documents.
>
> Michael
|
|
|
Re: CompareEditorInput setDirty difference between eclipse 3.2 and 3.3 [message #332973 is a reply to message #332955] |
Mon, 17 November 2008 16:05   |
Eclipse User |
|
|
|
Jan,
It is not API because it was not felt that it was ready to be promoted
(i.e. there are several issues with the class). I can't really comment
on whether it can be made API since I am not involved in the planning
for the compare component.
Michael
Jan Mauersberger wrote:
> Michael,
>
> thanks for the hints. However, I don't grasp how the
> SaveableCompareEditorInput can be used the way the ResourceCompareInput
> is working. It's furthermore abstract, located in the team plugin area
> and the available implementations are mainly team oriented and do not
> fit as the ResourceCompareInput does.
>
> Why is the ResourceCompareInput class internal anyway? It's perfect to
> directly compare two resources. As far as I can see it's only made
> available at user interface level (compare actions). Any chance to use
> it in code or any chance to have it available in future versions?
>
> Jan
>
>> The ResourceCompareInput class is internal to the Compare framework.
>> It's use by other clients is not supported. The
>> SaveableCompareEdiorInput was introduced in 3.3 and has support for
>> shared documents.
>>
>> Michael
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05118 seconds