Home » Modeling » EMF » ModificationTrackingAdapter criteria doesn't use isTouch
| ModificationTrackingAdapter criteria doesn't use isTouch [message #424533] |
Wed, 29 October 2008 16:55  |
 Linda Damus
Messages: 85
Registered: July 2009 |
Member |
|
|
Why does the ResourceImpl.ModificationTrackingAdapter use specific
notification types to determine whether or not the resource is modified
by the notification, rather than simply checking isTouch() on the
notification?
I would like to know because I've run into some inconsistencies between
EMF, EMF Transaction and GMF while working on the GMF bug to clear the
editor's dirty state when the operation history is undone back to the
last known save point (https://bugs.eclipse.org/bugs/show_bug.cgi?id=149214)
GMF uses the isModified state of the resource(s) to determine whether or
not a given GMF editor is dirty.
My approach so far has been to make use of the ResourceUndoContexts
added to undoable operations by the
WorkspaceCommandStackImpl.DomainListener. I have assumed that if an
operation has a ResourceUndoContext for a given resource, then the
operation has in some way changed the state of that resource. Once all
operations with the context for a given resource have been undone back
to the last known save point, if the resource is in a GMF editing domain
I will set the isModified state back to false.
At present, WorkspaceCommandStackImpl.DomainListener will add a
ResourceUndoContext for all notifications. I opened
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252378 to suggest that it
should ignore touch notifications, since they would not have changed the
state of the resource or its contents.
However, what I really want is that the criteria I use in GMF to
determine when to set the isModified state of a resource back to false
is the same as the criteria that were used to set isModified to true in
the firt place, i.e., the specific event types listed in
ResourceImpl.ModificationTrackingAdapter#notifyChanged. This leads me
to wonder what does isTouch() really mean, and why isn't it used as the
only criteria in ResourceImpl.ModificationTrackingAdapter#notifyChanged?
Thanks,
Linda
|
|
|
| Re: ModificationTrackingAdapter criteria doesn't use isTouch [message #424535 is a reply to message #424533] |
Wed, 29 October 2008 17:18  |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Linda,
Comments below.
Linda Damus wrote:
> Why does the ResourceImpl.ModificationTrackingAdapter use specific
> notification types to determine whether or not the resource is
> modified by the notification, rather than simply checking isTouch() on
> the notification?
Thats a good question!
>
> I would like to know because I've run into some inconsistencies
> between EMF, EMF Transaction and GMF while working on the GMF bug to
> clear the editor's dirty state when the operation history is undone
> back to the last known save point
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=149214)
>
> GMF uses the isModified state of the resource(s) to determine whether
> or not a given GMF editor is dirty.
Does undo undirty a resource?
>
> My approach so far has been to make use of the ResourceUndoContexts
> added to undoable operations by the
> WorkspaceCommandStackImpl.DomainListener. I have assumed that if an
> operation has a ResourceUndoContext for a given resource, then the
> operation has in some way changed the state of that resource. Once
> all operations with the context for a given resource have been undone
> back to the last known save point, if the resource is in a GMF editing
> domain I will set the isModified state back to false.
Well, that answers that. :-P
>
> At present, WorkspaceCommandStackImpl.DomainListener will add a
> ResourceUndoContext for all notifications. I opened
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=252378 to suggest that
> it should ignore touch notifications, since they would not have
> changed the state of the resource or its contents.
It's actually possible that a resource that's not dirty and hasn't been
touched, if saved, would produce a different result. That's because the
URI used to reference an object in a different resource could be changed...
>
> However, what I really want is that the criteria I use in GMF to
> determine when to set the isModified state of a resource back to false
> is the same as the criteria that were used to set isModified to true
> in the firt place, i.e., the specific event types listed in
> ResourceImpl.ModificationTrackingAdapter#notifyChanged. This leads me
> to wonder what does isTouch() really mean, and why isn't it used as
> the only criteria in
> ResourceImpl.ModificationTrackingAdapter#notifyChanged?
Looking at this I see that MOVE will always return false, so not much
point in checking that, but one might question if moving an object to
the same index it's at isn't a touch. The other question is the default
case.
public boolean isTouch()
{
switch (eventType)
{
case Notification.RESOLVE:
case Notification.REMOVING_ADAPTER:
{
return true;
}
case Notification.ADD:
case Notification.ADD_MANY:
case Notification.REMOVE:
case Notification.REMOVE_MANY:
case Notification.MOVE:
{
return false;
}
case Notification.SET:
case Notification.UNSET:
{
if (position == IS_SET_CHANGE_INDEX)
{
return false;
}
else
{
switch (primitiveType)
{
case PRIMITIVE_TYPE_BOOLEAN:
case PRIMITIVE_TYPE_BYTE:
case PRIMITIVE_TYPE_CHAR:
case PRIMITIVE_TYPE_LONG:
case PRIMITIVE_TYPE_INT:
case PRIMITIVE_TYPE_SHORT:
{
return oldSimplePrimitiveValue == newSimplePrimitiveValue;
}
case PRIMITIVE_TYPE_DOUBLE:
case PRIMITIVE_TYPE_FLOAT:
{
return oldIEEEPrimitiveValue == newIEEEPrimitiveValue;
}
default:
{
return oldValue == null ? newValue == null :
oldValue.equals(newValue);
}
}
}
}
default:
{
return false;
}
}
}
The handling of which specific case do you think is leading to the
inconsistency?
I would imagine that just looking at isTouch would be a good thing. The
MOVE case bothers me now that I look at it though...
>
> Thanks,
> Linda
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: ModificationTrackingAdapter criteria doesn't use isTouch [message #424538 is a reply to message #424535] |
Wed, 29 October 2008 18:51 |
Linda Damus
Messages: 85
Registered: July 2009 |
Member |
|
|
The inconsistency that I'm thinking about will occur when a non-touch
event of custom type is fired. The
WorkspaceCommandStackImpl.DomainListener will add a ResourceUndoContext
to the operation (if bug 252378 is legitimate and is addressed),
indicating that there is something to be undone for this resource, but
the ResourceImpl.ModificationTrackingAdapter will not set the modified
state of the resource to true.
Should there be a correlation between Notification#isTouch and
Resource#isModified, or should I think of them as two independent concepts?
Thanks,
Linda
Ed Merks wrote:
> Linda,
>
> Comments below.
>
>
> Linda Damus wrote:
>> Why does the ResourceImpl.ModificationTrackingAdapter use specific
>> notification types to determine whether or not the resource is
>> modified by the notification, rather than simply checking isTouch() on
>> the notification?
> Thats a good question!
>>
>> I would like to know because I've run into some inconsistencies
>> between EMF, EMF Transaction and GMF while working on the GMF bug to
>> clear the editor's dirty state when the operation history is undone
>> back to the last known save point
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=149214)
>>
>> GMF uses the isModified state of the resource(s) to determine whether
>> or not a given GMF editor is dirty.
> Does undo undirty a resource?
>>
>> My approach so far has been to make use of the ResourceUndoContexts
>> added to undoable operations by the
>> WorkspaceCommandStackImpl.DomainListener. I have assumed that if an
>> operation has a ResourceUndoContext for a given resource, then the
>> operation has in some way changed the state of that resource. Once
>> all operations with the context for a given resource have been undone
>> back to the last known save point, if the resource is in a GMF editing
>> domain I will set the isModified state back to false.
> Well, that answers that. :-P
>>
>> At present, WorkspaceCommandStackImpl.DomainListener will add a
>> ResourceUndoContext for all notifications. I opened
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=252378 to suggest that
>> it should ignore touch notifications, since they would not have
>> changed the state of the resource or its contents.
> It's actually possible that a resource that's not dirty and hasn't been
> touched, if saved, would produce a different result. That's because the
> URI used to reference an object in a different resource could be changed...
>>
>> However, what I really want is that the criteria I use in GMF to
>> determine when to set the isModified state of a resource back to false
>> is the same as the criteria that were used to set isModified to true
>> in the firt place, i.e., the specific event types listed in
>> ResourceImpl.ModificationTrackingAdapter#notifyChanged. This leads me
>> to wonder what does isTouch() really mean, and why isn't it used as
>> the only criteria in
>> ResourceImpl.ModificationTrackingAdapter#notifyChanged?
> Looking at this I see that MOVE will always return false, so not much
> point in checking that, but one might question if moving an object to
> the same index it's at isn't a touch. The other question is the default
> case.
>
> public boolean isTouch()
> {
> switch (eventType)
> {
> case Notification.RESOLVE:
> case Notification.REMOVING_ADAPTER:
> {
> return true;
> }
> case Notification.ADD:
> case Notification.ADD_MANY:
> case Notification.REMOVE:
> case Notification.REMOVE_MANY:
> case Notification.MOVE:
> {
> return false;
> }
> case Notification.SET:
> case Notification.UNSET:
> {
> if (position == IS_SET_CHANGE_INDEX)
> {
> return false;
> }
> else
> {
> switch (primitiveType)
> {
> case PRIMITIVE_TYPE_BOOLEAN:
> case PRIMITIVE_TYPE_BYTE:
> case PRIMITIVE_TYPE_CHAR:
> case PRIMITIVE_TYPE_LONG:
> case PRIMITIVE_TYPE_INT:
> case PRIMITIVE_TYPE_SHORT:
> {
> return oldSimplePrimitiveValue == newSimplePrimitiveValue;
> }
> case PRIMITIVE_TYPE_DOUBLE:
> case PRIMITIVE_TYPE_FLOAT:
> {
> return oldIEEEPrimitiveValue == newIEEEPrimitiveValue;
> }
> default:
> {
> return oldValue == null ? newValue == null :
> oldValue.equals(newValue);
> }
> }
> }
> }
> default:
> {
> return false;
> }
> }
> }
>
> The handling of which specific case do you think is leading to the
> inconsistency?
>
> I would imagine that just looking at isTouch would be a good thing. The
> MOVE case bothers me now that I look at it though...
>>
>> Thanks,
>> Linda
|
|
|
| Re: ModificationTrackingAdapter criteria doesn't use isTouch [message #424540 is a reply to message #424538] |
Wed, 29 October 2008 18:59 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Linda,
Comments below.
Linda Damus wrote:
> The inconsistency that I'm thinking about will occur when a non-touch
> event of custom type is fired.
What's that? One of the event types that isn't handled by the switch
and that would return isTouch false by default? It seems reasonable
perhaps that the framework ought to assume that anything else isn't
really a change...
> The WorkspaceCommandStackImpl.DomainListener will add a
> ResourceUndoContext to the operation (if bug 252378 is legitimate and
> is addressed), indicating that there is something to be undone for
> this resource, but the ResourceImpl.ModificationTrackingAdapter will
> not set the modified state of the resource to true.
>
> Should there be a correlation between Notification#isTouch and
> Resource#isModified, or should I think of them as two independent
> concepts?
It seems reasonable to argue they should correspond exactly. A custom
touch even could be responsible for controlling is isTouch returns true
so that's more flexible than what's there which assumes only a fixed set
of event types imply touch...
The move thing continues to bother me. It's all your fault for making
me look at it! :-P
>
> Thanks,
> Linda
>
> Ed Merks wrote:
>> Linda,
>>
>> Comments below.
>>
>>
>> Linda Damus wrote:
>>> Why does the ResourceImpl.ModificationTrackingAdapter use specific
>>> notification types to determine whether or not the resource is
>>> modified by the notification, rather than simply checking isTouch()
>>> on the notification?
>> Thats a good question!
>>>
>>> I would like to know because I've run into some inconsistencies
>>> between EMF, EMF Transaction and GMF while working on the GMF bug to
>>> clear the editor's dirty state when the operation history is undone
>>> back to the last known save point
>>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=149214)
>>>
>>> GMF uses the isModified state of the resource(s) to determine
>>> whether or not a given GMF editor is dirty.
>> Does undo undirty a resource?
>>>
>>> My approach so far has been to make use of the ResourceUndoContexts
>>> added to undoable operations by the
>>> WorkspaceCommandStackImpl.DomainListener. I have assumed that if an
>>> operation has a ResourceUndoContext for a given resource, then the
>>> operation has in some way changed the state of that resource. Once
>>> all operations with the context for a given resource have been
>>> undone back to the last known save point, if the resource is in a
>>> GMF editing domain I will set the isModified state back to false.
>> Well, that answers that. :-P
>>>
>>> At present, WorkspaceCommandStackImpl.DomainListener will add a
>>> ResourceUndoContext for all notifications. I opened
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=252378 to suggest that
>>> it should ignore touch notifications, since they would not have
>>> changed the state of the resource or its contents.
>> It's actually possible that a resource that's not dirty and hasn't
>> been touched, if saved, would produce a different result. That's
>> because the URI used to reference an object in a different resource
>> could be changed...
>>>
>>> However, what I really want is that the criteria I use in GMF to
>>> determine when to set the isModified state of a resource back to
>>> false is the same as the criteria that were used to set isModified
>>> to true in the firt place, i.e., the specific event types listed in
>>> ResourceImpl.ModificationTrackingAdapter#notifyChanged. This leads
>>> me to wonder what does isTouch() really mean, and why isn't it used
>>> as the only criteria in
>>> ResourceImpl.ModificationTrackingAdapter#notifyChanged?
>> Looking at this I see that MOVE will always return false, so not much
>> point in checking that, but one might question if moving an object to
>> the same index it's at isn't a touch. The other question is the
>> default case.
>>
>> public boolean isTouch()
>> {
>> switch (eventType)
>> {
>> case Notification.RESOLVE:
>> case Notification.REMOVING_ADAPTER:
>> {
>> return true;
>> }
>> case Notification.ADD:
>> case Notification.ADD_MANY:
>> case Notification.REMOVE:
>> case Notification.REMOVE_MANY:
>> case Notification.MOVE:
>> {
>> return false;
>> }
>> case Notification.SET:
>> case Notification.UNSET:
>> {
>> if (position == IS_SET_CHANGE_INDEX)
>> {
>> return false;
>> }
>> else
>> {
>> switch (primitiveType)
>> {
>> case PRIMITIVE_TYPE_BOOLEAN:
>> case PRIMITIVE_TYPE_BYTE:
>> case PRIMITIVE_TYPE_CHAR:
>> case PRIMITIVE_TYPE_LONG:
>> case PRIMITIVE_TYPE_INT:
>> case PRIMITIVE_TYPE_SHORT:
>> {
>> return oldSimplePrimitiveValue == newSimplePrimitiveValue;
>> }
>> case PRIMITIVE_TYPE_DOUBLE:
>> case PRIMITIVE_TYPE_FLOAT:
>> {
>> return oldIEEEPrimitiveValue == newIEEEPrimitiveValue;
>> }
>> default:
>> {
>> return oldValue == null ? newValue == null :
>> oldValue.equals(newValue);
>> }
>> }
>> }
>> }
>> default:
>> {
>> return false;
>> }
>> }
>> }
>>
>> The handling of which specific case do you think is leading to the
>> inconsistency?
>>
>> I would imagine that just looking at isTouch would be a good thing.
>> The MOVE case bothers me now that I look at it though...
>>>
>>> Thanks,
>>> Linda
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: ModificationTrackingAdapter criteria doesn't use isTouch [message #424626 is a reply to message #424540] |
Fri, 31 October 2008 15:10 |
Linda Damus
Messages: 85
Registered: July 2009 |
Member |
|
|
Thanks, Ed. Your advice and extraordinary client support is, as always,
very much appreciated.
Yes, I was referring to an event type that's not handled in the switch
but that returns isTouch false. Agreed that it's reasonable for the
framework to assume it's not a change, but also agreed that it's more
flexible if the framework consults isTouch, which I can implement the
way I want.
I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=252981 to
request the change to use isTouch in
ResourceImpl.ModificationTrackingAdapter. Would you like me to open
another one for the move issue?
Thanks,
Linda
Ed Merks wrote:
> Linda,
>
> Comments below.
>
> Linda Damus wrote:
>> The inconsistency that I'm thinking about will occur when a non-touch
>> event of custom type is fired.
> What's that? One of the event types that isn't handled by the switch
> and that would return isTouch false by default? It seems reasonable
> perhaps that the framework ought to assume that anything else isn't
> really a change...
>> The WorkspaceCommandStackImpl.DomainListener will add a
>> ResourceUndoContext to the operation (if bug 252378 is legitimate and
>> is addressed), indicating that there is something to be undone for
>> this resource, but the ResourceImpl.ModificationTrackingAdapter will
>> not set the modified state of the resource to true.
>>
>> Should there be a correlation between Notification#isTouch and
>> Resource#isModified, or should I think of them as two independent
>> concepts?
> It seems reasonable to argue they should correspond exactly. A custom
> touch even could be responsible for controlling is isTouch returns true
> so that's more flexible than what's there which assumes only a fixed set
> of event types imply touch...
>
> The move thing continues to bother me. It's all your fault for making
> me look at it! :-P
>>
>> Thanks,
>> Linda
>>
>> Ed Merks wrote:
>>> Linda,
>>>
>>> Comments below.
>>>
>>>
>>> Linda Damus wrote:
>>>> Why does the ResourceImpl.ModificationTrackingAdapter use specific
>>>> notification types to determine whether or not the resource is
>>>> modified by the notification, rather than simply checking isTouch()
>>>> on the notification?
>>> Thats a good question!
>>>>
>>>> I would like to know because I've run into some inconsistencies
>>>> between EMF, EMF Transaction and GMF while working on the GMF bug to
>>>> clear the editor's dirty state when the operation history is undone
>>>> back to the last known save point
>>>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=149214)
>>>>
>>>> GMF uses the isModified state of the resource(s) to determine
>>>> whether or not a given GMF editor is dirty.
>>> Does undo undirty a resource?
>>>>
>>>> My approach so far has been to make use of the ResourceUndoContexts
>>>> added to undoable operations by the
>>>> WorkspaceCommandStackImpl.DomainListener. I have assumed that if an
>>>> operation has a ResourceUndoContext for a given resource, then the
>>>> operation has in some way changed the state of that resource. Once
>>>> all operations with the context for a given resource have been
>>>> undone back to the last known save point, if the resource is in a
>>>> GMF editing domain I will set the isModified state back to false.
>>> Well, that answers that. :-P
>>>>
>>>> At present, WorkspaceCommandStackImpl.DomainListener will add a
>>>> ResourceUndoContext for all notifications. I opened
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=252378 to suggest that
>>>> it should ignore touch notifications, since they would not have
>>>> changed the state of the resource or its contents.
>>> It's actually possible that a resource that's not dirty and hasn't
>>> been touched, if saved, would produce a different result. That's
>>> because the URI used to reference an object in a different resource
>>> could be changed...
>>>>
>>>> However, what I really want is that the criteria I use in GMF to
>>>> determine when to set the isModified state of a resource back to
>>>> false is the same as the criteria that were used to set isModified
>>>> to true in the firt place, i.e., the specific event types listed in
>>>> ResourceImpl.ModificationTrackingAdapter#notifyChanged. This leads
>>>> me to wonder what does isTouch() really mean, and why isn't it used
>>>> as the only criteria in
>>>> ResourceImpl.ModificationTrackingAdapter#notifyChanged?
>>> Looking at this I see that MOVE will always return false, so not much
>>> point in checking that, but one might question if moving an object to
>>> the same index it's at isn't a touch. The other question is the
>>> default case.
>>>
>>> public boolean isTouch()
>>> {
>>> switch (eventType)
>>> {
>>> case Notification.RESOLVE:
>>> case Notification.REMOVING_ADAPTER:
>>> {
>>> return true;
>>> }
>>> case Notification.ADD:
>>> case Notification.ADD_MANY:
>>> case Notification.REMOVE:
>>> case Notification.REMOVE_MANY:
>>> case Notification.MOVE:
>>> {
>>> return false;
>>> }
>>> case Notification.SET:
>>> case Notification.UNSET:
>>> {
>>> if (position == IS_SET_CHANGE_INDEX)
>>> {
>>> return false;
>>> }
>>> else
>>> {
>>> switch (primitiveType)
>>> {
>>> case PRIMITIVE_TYPE_BOOLEAN:
>>> case PRIMITIVE_TYPE_BYTE:
>>> case PRIMITIVE_TYPE_CHAR:
>>> case PRIMITIVE_TYPE_LONG:
>>> case PRIMITIVE_TYPE_INT:
>>> case PRIMITIVE_TYPE_SHORT:
>>> {
>>> return oldSimplePrimitiveValue == newSimplePrimitiveValue;
>>> }
>>> case PRIMITIVE_TYPE_DOUBLE:
>>> case PRIMITIVE_TYPE_FLOAT:
>>> {
>>> return oldIEEEPrimitiveValue == newIEEEPrimitiveValue;
>>> }
>>> default:
>>> {
>>> return oldValue == null ? newValue == null :
>>> oldValue.equals(newValue);
>>> }
>>> }
>>> }
>>> }
>>> default:
>>> {
>>> return false;
>>> }
>>> }
>>> }
>>>
>>> The handling of which specific case do you think is leading to the
>>> inconsistency?
>>>
>>> I would imagine that just looking at isTouch would be a good thing.
>>> The MOVE case bothers me now that I look at it though...
>>>>
>>>> Thanks,
>>>> Linda
|
|
|
| Re: ModificationTrackingAdapter criteria doesn't use isTouch [message #424627 is a reply to message #424626] |
Fri, 31 October 2008 15:27 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Linda,
I put a patch for both issues in the bugzilla.
Linda Damus wrote:
> Thanks, Ed. Your advice and extraordinary client support is, as
> always, very much appreciated.
>
> Yes, I was referring to an event type that's not handled in the switch
> but that returns isTouch false. Agreed that it's reasonable for the
> framework to assume it's not a change, but also agreed that it's more
> flexible if the framework consults isTouch, which I can implement the
> way I want.
>
> I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=252981 to
> request the change to use isTouch in
> ResourceImpl.ModificationTrackingAdapter. Would you like me to open
> another one for the move issue?
>
> Thanks,
> Linda
>
>
> Ed Merks wrote:
>> Linda,
>>
>> Comments below.
>>
>> Linda Damus wrote:
>>> The inconsistency that I'm thinking about will occur when a
>>> non-touch event of custom type is fired.
>> What's that? One of the event types that isn't handled by the
>> switch and that would return isTouch false by default? It seems
>> reasonable perhaps that the framework ought to assume that anything
>> else isn't really a change...
>>> The WorkspaceCommandStackImpl.DomainListener will add a
>>> ResourceUndoContext to the operation (if bug 252378 is legitimate
>>> and is addressed), indicating that there is something to be undone
>>> for this resource, but the ResourceImpl.ModificationTrackingAdapter
>>> will not set the modified state of the resource to true.
>>>
>>> Should there be a correlation between Notification#isTouch and
>>> Resource#isModified, or should I think of them as two independent
>>> concepts?
>> It seems reasonable to argue they should correspond exactly. A
>> custom touch even could be responsible for controlling is isTouch
>> returns true so that's more flexible than what's there which assumes
>> only a fixed set of event types imply touch...
>>
>> The move thing continues to bother me. It's all your fault for
>> making me look at it! :-P
>>>
>>> Thanks,
>>> Linda
>>>
>>> Ed Merks wrote:
>>>> Linda,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Linda Damus wrote:
>>>>> Why does the ResourceImpl.ModificationTrackingAdapter use specific
>>>>> notification types to determine whether or not the resource is
>>>>> modified by the notification, rather than simply checking
>>>>> isTouch() on the notification?
>>>> Thats a good question!
>>>>>
>>>>> I would like to know because I've run into some inconsistencies
>>>>> between EMF, EMF Transaction and GMF while working on the GMF bug
>>>>> to clear the editor's dirty state when the operation history is
>>>>> undone back to the last known save point
>>>>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=149214)
>>>>>
>>>>> GMF uses the isModified state of the resource(s) to determine
>>>>> whether or not a given GMF editor is dirty.
>>>> Does undo undirty a resource?
>>>>>
>>>>> My approach so far has been to make use of the
>>>>> ResourceUndoContexts added to undoable operations by the
>>>>> WorkspaceCommandStackImpl.DomainListener. I have assumed that if
>>>>> an operation has a ResourceUndoContext for a given resource, then
>>>>> the operation has in some way changed the state of that resource.
>>>>> Once all operations with the context for a given resource have
>>>>> been undone back to the last known save point, if the resource is
>>>>> in a GMF editing domain I will set the isModified state back to
>>>>> false.
>>>> Well, that answers that. :-P
>>>>>
>>>>> At present, WorkspaceCommandStackImpl.DomainListener will add a
>>>>> ResourceUndoContext for all notifications. I opened
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=252378 to suggest
>>>>> that it should ignore touch notifications, since they would not
>>>>> have changed the state of the resource or its contents.
>>>> It's actually possible that a resource that's not dirty and hasn't
>>>> been touched, if saved, would produce a different result. That's
>>>> because the URI used to reference an object in a different resource
>>>> could be changed...
>>>>>
>>>>> However, what I really want is that the criteria I use in GMF to
>>>>> determine when to set the isModified state of a resource back to
>>>>> false is the same as the criteria that were used to set isModified
>>>>> to true in the firt place, i.e., the specific event types listed
>>>>> in ResourceImpl.ModificationTrackingAdapter#notifyChanged. This
>>>>> leads me to wonder what does isTouch() really mean, and why isn't
>>>>> it used as the only criteria in
>>>>> ResourceImpl.ModificationTrackingAdapter#notifyChanged?
>>>> Looking at this I see that MOVE will always return false, so not
>>>> much point in checking that, but one might question if moving an
>>>> object to the same index it's at isn't a touch. The other question
>>>> is the default case.
>>>>
>>>> public boolean isTouch()
>>>> {
>>>> switch (eventType)
>>>> {
>>>> case Notification.RESOLVE:
>>>> case Notification.REMOVING_ADAPTER:
>>>> {
>>>> return true;
>>>> }
>>>> case Notification.ADD:
>>>> case Notification.ADD_MANY:
>>>> case Notification.REMOVE:
>>>> case Notification.REMOVE_MANY:
>>>> case Notification.MOVE:
>>>> {
>>>> return false;
>>>> }
>>>> case Notification.SET:
>>>> case Notification.UNSET:
>>>> {
>>>> if (position == IS_SET_CHANGE_INDEX)
>>>> {
>>>> return false;
>>>> }
>>>> else
>>>> {
>>>> switch (primitiveType)
>>>> {
>>>> case PRIMITIVE_TYPE_BOOLEAN:
>>>> case PRIMITIVE_TYPE_BYTE:
>>>> case PRIMITIVE_TYPE_CHAR:
>>>> case PRIMITIVE_TYPE_LONG:
>>>> case PRIMITIVE_TYPE_INT:
>>>> case PRIMITIVE_TYPE_SHORT:
>>>> {
>>>> return oldSimplePrimitiveValue ==
>>>> newSimplePrimitiveValue;
>>>> }
>>>> case PRIMITIVE_TYPE_DOUBLE:
>>>> case PRIMITIVE_TYPE_FLOAT:
>>>> {
>>>> return oldIEEEPrimitiveValue == newIEEEPrimitiveValue;
>>>> }
>>>> default:
>>>> {
>>>> return oldValue == null ? newValue == null :
>>>> oldValue.equals(newValue);
>>>> }
>>>> }
>>>> }
>>>> }
>>>> default:
>>>> {
>>>> return false;
>>>> }
>>>> }
>>>> }
>>>>
>>>> The handling of which specific case do you think is leading to the
>>>> inconsistency?
>>>>
>>>> I would imagine that just looking at isTouch would be a good
>>>> thing. The MOVE case bothers me now that I look at it though...
>>>>>
>>>>> Thanks,
>>>>> Linda
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 04:16:55 GMT 2024
Powered by FUDForum. Page generated in 0.04124 seconds |
] 
Search
Help
Register
Login
Home
