Eclipse Community Forums: Eclipse Platform » CompareEditorInput setDirty difference between eclipse 3.2 and 3.3

Help

Home

Home » Eclipse Projects » Eclipse Platform » CompareEditorInput setDirty difference between eclipse 3.2 and 3.3

Show: Today's Messages :: Show Polls :: Message Navigator

CompareEditorInput setDirty difference between eclipse 3.2 and 3.3 [message #328960]

Mon, 09 June 2008 11:57

Jan Mauersberger

Messages: 120
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Michael Valenta

Messages: 35
Registered: July 2009

Member

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

Report message to a moderator

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

Jan Mauersberger

Messages: 120
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Jan Mauersberger

Messages: 120
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Michael Valenta

Messages: 35
Registered: July 2009

Member

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

Report message to a moderator

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

Jan Mauersberger

Messages: 120
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Michael Valenta

Messages: 35
Registered: July 2009

Member

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

Report message to a moderator

Re: CompareEditorInput setDirty difference between eclipse 3.2 and 3.3 [message #332975 is a reply to message #332973]

Mon, 17 November 2008 16:38

Szymon Brandys

Messages: 11
Registered: July 2009

Junior Member

You can check the development plan, which includes compare and team items
here http://www.eclipse.org/eclipse/platform-team/team3.5/plan.ph p.

We haven't planned to make it API, however this could happen while fixing
for instance https://bugs.eclipse.org/bugs/show_bug.cgi?id=193324.

I have to check what are the issues mentioned by Mike and how big effort
is needed to fix them. So far I'm not able to say anything more precise.

Szymon

Michael Valenta wrote:

> 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.

Report message to a moderator

Re: CompareEditorInput setDirty difference between eclipse 3.2 and 3.3 [message #332984 is a reply to message #332975]

Tue, 18 November 2008 07:35

Jan Mauersberger

Messages: 120
Registered: July 2009

Senior Member

Thanks both of you for the valuable information. When it comes to
opening the package to the API I would like to contribute if possible
and necessary (I identified some problems over time).

Jan

> You can check the development plan, which includes compare and team
> items here http://www.eclipse.org/eclipse/platform-team/team3.5/plan.ph p.
>
> We haven't planned to make it API, however this could happen while
> fixing for instance https://bugs.eclipse.org/bugs/show_bug.cgi?id=193324.
>
> I have to check what are the issues mentioned by Mike and how big effort
> is needed to fix them. So far I'm not able to say anything more precise.
>
> Szymon
>

Report message to a moderator

Previous Topic:	References to a method
Next Topic:	Eclipse view plugin: swing problem

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Jan 03 01:26:35 GMT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter