Home » Modeling » GMF (Graphical Modeling Framework) » Configuring Copy/Paste does not work
| Configuring Copy/Paste does not work [message #163901] |
Mon, 03 December 2007 17:23  |
 No real name
Messages: 33
Registered: July 2009 |
Member |
|
|
Hi,
How do I prevent (non-containment) EReferences from being copied to the
clipboard?
In my diagram, connections are attached to side affixed children of the
nodes rather than to the nodes themselves. These child nodes are
contained elements in the semantic model.
So the ecore model looks like
TopNodeElement <>--- ChildElement <----------------> ConnectionElement
children* source 1 outConn 0..1
When I copy a top node with a connected child, the semantic model
section of the clipboard string roughly looks like
....
<TopNode>
<children xmi:type="ChildNode".../>
<outConn xmi:type="ConnectionElement".../>
....
even though the connection has not been selected. Pasting this, results
in the connection element being reconnected to the clone, as the
EReference source (the eOpposite of outConn) has multiplicity 1.
I have already tried to implement my own
NotationClipboardOperationHelper but it does not make a difference. E.g.
the isCopyAlways method is only called on the semantic top node
element, neither on its child nor on the reference connection.
Similarly, the collection returned by getExcludedCopyObjects() is only
taken into account on the top node and child semantic elements, the
latter is then copied including the buggy reference.
How do I prevent this EReference from being copied? Must I write my own
override copy commands, or am I missing something?
Regards
Jan.
|
|
|
| Re: Configuring Copy/Paste does not work [message #163907 is a reply to message #163901] |
Mon, 03 December 2007 17:55  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Jan,
See some replies in-line, below.
Cheers,
Christian
Jan Köhnlein wrote:
> Hi,
>
> How do I prevent (non-containment) EReferences from being copied to the
> clipboard?
>
> In my diagram, connections are attached to side affixed children of the
> nodes rather than to the nodes themselves. These child nodes are
> contained elements in the semantic model.
>
> So the ecore model looks like
> TopNodeElement <>--- ChildElement <----------------> ConnectionElement
> children* source 1 outConn 0..1
>
> When I copy a top node with a connected child, the semantic model
> section of the clipboard string roughly looks like
>
> ...
> <TopNode>
> <children xmi:type="ChildNode".../>
> <outConn xmi:type="ConnectionElement".../>
> ...
>
> even though the connection has not been selected. Pasting this, results
> in the connection element being reconnected to the clone, as the
> EReference source (the eOpposite of outConn) has multiplicity 1.
The default copy/paste implementation should never copy a reference whose
opposite has multiplicity 1, unless the referred object is also being
copied (in which case, the two copied objects would be correctly
associated). This sounds like a bug.
> I have already tried to implement my own
> NotationClipboardOperationHelper but it does not make a difference. E.g.
Rather than that, I think you need to create a AbstractClipboardSupport for
your semantic model EPackage, not for the notation model.
> the isCopyAlways method is only called on the semantic top node
> element, neither on its child nor on the reference connection.
> Similarly, the collection returned by getExcludedCopyObjects() is only
> taken into account on the top node and child semantic elements, the
> latter is then copied including the buggy reference.
AFIACS, the CopyOperation recursively processes the selected objects to
check for copy-always references. However, in your case, the semantic
model elements are not selected, but referenced by selected objects (the
diagram views). It looks like copy-always isn't being recursively applied
to objects included by copy-always, which might be a bug. However,
implementing an AbstractClipboardSupport for your semantic model might fix
that.
> How do I prevent this EReference from being copied? Must I write my own
> override copy commands, or am I missing something?
>
> Regards
> Jan.
|
|
|
| Re: Configuring Copy/Paste does not work [message #163919 is a reply to message #163907] |
Mon, 03 December 2007 20:18 |
No real name
Messages: 33
Registered: July 2009 |
Member |
|
|
Thanks for your replies, Christian. You describe exactly how I expected
copy/paste to be working - from an EMF perspective. Unfortunately, the
GMF code looks a lot different.
I've already tried to register an clipboard support for my metamodel by
means of an extension, a factory and inheriting from
AbstractClipboardSupport. Unfortunately, GMF's copy/paste mechanism is
ignoring that. The reason is it does *not* recurse the semantic model
elements.
Instead, it collects some "CopyObjects", which is a bunch of several
more or less obscure sets and maps whose contents are at least in the
case of the semantic model more or less deeply copied without further
callbacks :-(
The only way I found to hook into copy/paste at all was to register a
ClipboardSupportFactory for the Notation model with at least low
priority. But from my experience so far that easily leads to rewriting
the whole copy/paste mechanism from scratch, or at least copying a huge
amount of code. It seems that GMF is not ready to be configurable in
that regard.
I can summarize that GMF has its own very special way of handling
copy/paste. Given that, it's really not a big help that GMF's clipboard
docs forward to the EMF clipboard docs. From my own experience, I know
copy/paste is a very complicated thing, especially when there's a
graphical and a semantic model. But some piece of documentation how the
specific GMF stuff is meant to work - and how it could possibly be
extended - would be very appreciated.
Regards
Jan
Christian W. Damus schrieb:
> Hi, Jan,
>
> See some replies in-line, below.
>
> Cheers,
>
> Christian
>
> Jan Köhnlein wrote:
>
>> Hi,
>>
>> How do I prevent (non-containment) EReferences from being copied to the
>> clipboard?
>>
>> In my diagram, connections are attached to side affixed children of the
>> nodes rather than to the nodes themselves. These child nodes are
>> contained elements in the semantic model.
>>
>> So the ecore model looks like
>> TopNodeElement <>--- ChildElement <----------------> ConnectionElement
>> children* source 1 outConn 0..1
>>
>> When I copy a top node with a connected child, the semantic model
>> section of the clipboard string roughly looks like
>>
>> ...
>> <TopNode>
>> <children xmi:type="ChildNode".../>
>> <outConn xmi:type="ConnectionElement".../>
>> ...
>>
>> even though the connection has not been selected. Pasting this, results
>> in the connection element being reconnected to the clone, as the
>> EReference source (the eOpposite of outConn) has multiplicity 1.
>
> The default copy/paste implementation should never copy a reference whose
> opposite has multiplicity 1, unless the referred object is also being
> copied (in which case, the two copied objects would be correctly
> associated). This sounds like a bug.
>
>
>> I have already tried to implement my own
>> NotationClipboardOperationHelper but it does not make a difference. E.g.
>
> Rather than that, I think you need to create a AbstractClipboardSupport for
> your semantic model EPackage, not for the notation model.
>
>
>> the isCopyAlways method is only called on the semantic top node
>> element, neither on its child nor on the reference connection.
>> Similarly, the collection returned by getExcludedCopyObjects() is only
>> taken into account on the top node and child semantic elements, the
>> latter is then copied including the buggy reference.
>
> AFIACS, the CopyOperation recursively processes the selected objects to
> check for copy-always references. However, in your case, the semantic
> model elements are not selected, but referenced by selected objects (the
> diagram views). It looks like copy-always isn't being recursively applied
> to objects included by copy-always, which might be a bug. However,
> implementing an AbstractClipboardSupport for your semantic model might fix
> that.
>
>
>> How do I prevent this EReference from being copied? Must I write my own
>> override copy commands, or am I missing something?
>>
>> Regards
>> Jan.
>
|
|
|
| Re: Configuring Copy/Paste does not work [message #164200 is a reply to message #163919] |
Tue, 04 December 2007 14:41 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Jan,
See some more replies in-line, below.
Cheers,
Christian
Jan Köhnlein wrote:
> Thanks for your replies, Christian. You describe exactly how I expected
> copy/paste to be working - from an EMF perspective. Unfortunately, the
> GMF code looks a lot different.
>
> I've already tried to register an clipboard support for my metamodel by
> means of an extension, a factory and inheriting from
> AbstractClipboardSupport. Unfortunately, GMF's copy/paste mechanism is
> ignoring that. The reason is it does *not* recurse the semantic model
> elements.
Right, sorry. I forgot that there is an open enhancement requesting support
for Copy/Paste operations on heterogeneous selections to utilize multiple
clipboard-support extensions:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=138255
I imagine this enhancement would also need to bridge clipboard-supports when
following references from one metamodel to another.
> Instead, it collects some "CopyObjects", which is a bunch of several
> more or less obscure sets and maps whose contents are at least in the
> case of the semantic model more or less deeply copied without further
> callbacks :-(
>
> The only way I found to hook into copy/paste at all was to register a
> ClipboardSupportFactory for the Notation model with at least low
> priority. But from my experience so far that easily leads to rewriting
> the whole copy/paste mechanism from scratch, or at least copying a huge
> amount of code. It seems that GMF is not ready to be configurable in
> that regard.
Right, currently you would have to override/extend the notation
clibpoard-support. This is why bug 138255 would be a real nice-to-have. I
think, essentially, your problem is a Use Case for this enhancement.
Perhaps you can record your requirements on this enhancement in bugzilla?
> I can summarize that GMF has its own very special way of handling
> copy/paste. Given that, it's really not a big help that GMF's clipboard
Yes, the goal of GMF's copy/paste framework is two-fold: to handle more
complex inter-object dependencies than what can be expressed in Ecore, and
to serialize copied objects to the system clipboard for copy/paste across
editing domains or even Eclipse instances.
> docs forward to the EMF clipboard docs. From my own experience, I know
> copy/paste is a very complicated thing, especially when there's a
> graphical and a semantic model. But some piece of documentation how the
> specific GMF stuff is meant to work - and how it could possibly be
> extended - would be very appreciated.
Yes, GMF's extensible copy/paste documentation so far basically consists of
an example plug-in for the "EXTLibrary" example model from EMF:
org.eclipse.gmf.examples.runtime.emf.clipboard. As you seem to be
exploring the clipboard framework in detail, you might be in a good
position to contribute to the documentation! ;-)
> Regards
> Jan
>
> Christian W. Damus schrieb:
>> Hi, Jan,
>>
>> See some replies in-line, below.
>>
>> Cheers,
>>
>> Christian
>>
>> Jan Köhnlein wrote:
>>
>>> Hi,
>>>
>>> How do I prevent (non-containment) EReferences from being copied to the
>>> clipboard?
>>>
>>> In my diagram, connections are attached to side affixed children of the
>>> nodes rather than to the nodes themselves. These child nodes are
>>> contained elements in the semantic model.
>>>
>>> So the ecore model looks like
>>> TopNodeElement <>--- ChildElement <----------------> ConnectionElement
>>> children* source 1 outConn 0..1
>>>
>>> When I copy a top node with a connected child, the semantic model
>>> section of the clipboard string roughly looks like
>>>
>>> ...
>>> <TopNode>
>>> <children xmi:type="ChildNode".../>
>>> <outConn xmi:type="ConnectionElement".../>
>>> ...
>>>
>>> even though the connection has not been selected. Pasting this, results
>>> in the connection element being reconnected to the clone, as the
>>> EReference source (the eOpposite of outConn) has multiplicity 1.
>>
>> The default copy/paste implementation should never copy a reference whose
>> opposite has multiplicity 1, unless the referred object is also being
>> copied (in which case, the two copied objects would be correctly
>> associated). This sounds like a bug.
>>
>>
>>> I have already tried to implement my own
>>> NotationClipboardOperationHelper but it does not make a difference. E.g.
>>
>> Rather than that, I think you need to create a AbstractClipboardSupport
>> for your semantic model EPackage, not for the notation model.
>>
>>
>>> the isCopyAlways method is only called on the semantic top node
>>> element, neither on its child nor on the reference connection.
>>> Similarly, the collection returned by getExcludedCopyObjects() is only
>>> taken into account on the top node and child semantic elements, the
>>> latter is then copied including the buggy reference.
>>
>> AFIACS, the CopyOperation recursively processes the selected objects to
>> check for copy-always references. However, in your case, the semantic
>> model elements are not selected, but referenced by selected objects (the
>> diagram views). It looks like copy-always isn't being recursively
>> applied
>> to objects included by copy-always, which might be a bug. However,
>> implementing an AbstractClipboardSupport for your semantic model might
>> fix that.
>>
>>
>>> How do I prevent this EReference from being copied? Must I write my own
>>> override copy commands, or am I missing something?
>>>
>>> Regards
>>> Jan.
>>
|
|
|
| Re: Configuring Copy/Paste does not work [message #164298 is a reply to message #164200] |
Tue, 04 December 2007 19:55 |
No real name
Messages: 33
Registered: July 2009 |
Member |
|
|
I found a workaround now for my specific use case. The main idea of the
solution is to override the SavingEMFResource used by the CopyOperation.
It now instantiates a special XMLSaveImpl that skips the serialisation
of some references under certain circumstances (shouldSaveFeature()).
To get these changes into my application without changing the framework
itself - which is a major concern here for compatibility reasons - has
been quite a hassle. It involved copying quite some code. I would
appreciate, if the GMF runtime code would be a little more friendly to
changes, e.g. by using less (package) private members or offering at
least protected getters.
As I have already mentioned, the current workaround is very specific to
my metamodel.
A general solution should look for references to semantic model elements
which are mapped onto connections that have not been selected, and skip
these in the serialization step. Not an easy task, given that
understanding enough of the current architecture of copy/paste to find a
workaround took me about one and a half day. And still I only scratched
the surface (e.g. only the copy part). To find out enough in order to be
able to write the documentation would take me several more weeks, which
I do not have. Into the bargain, I don't think reverse engineering the
architecture from code of that complexity just to be able to write the
docs is a good idea. Nevertheless, I will record my observations in
bugzilla as soon as I find the time.
Regards
Jan
Christian W. Damus schrieb:
> Hi, Jan,
>
> See some more replies in-line, below.
>
> Cheers,
>
> Christian
>
>
> Jan Köhnlein wrote:
>
>> Thanks for your replies, Christian. You describe exactly how I expected
>> copy/paste to be working - from an EMF perspective. Unfortunately, the
>> GMF code looks a lot different.
>>
>> I've already tried to register an clipboard support for my metamodel by
>> means of an extension, a factory and inheriting from
>> AbstractClipboardSupport. Unfortunately, GMF's copy/paste mechanism is
>> ignoring that. The reason is it does *not* recurse the semantic model
>> elements.
>
> Right, sorry. I forgot that there is an open enhancement requesting support
> for Copy/Paste operations on heterogeneous selections to utilize multiple
> clipboard-support extensions:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=138255
>
> I imagine this enhancement would also need to bridge clipboard-supports when
> following references from one metamodel to another.
>
>
>> Instead, it collects some "CopyObjects", which is a bunch of several
>> more or less obscure sets and maps whose contents are at least in the
>> case of the semantic model more or less deeply copied without further
>> callbacks :-(
>>
>> The only way I found to hook into copy/paste at all was to register a
>> ClipboardSupportFactory for the Notation model with at least low
>> priority. But from my experience so far that easily leads to rewriting
>> the whole copy/paste mechanism from scratch, or at least copying a huge
>> amount of code. It seems that GMF is not ready to be configurable in
>> that regard.
>
> Right, currently you would have to override/extend the notation
> clibpoard-support. This is why bug 138255 would be a real nice-to-have. I
> think, essentially, your problem is a Use Case for this enhancement.
> Perhaps you can record your requirements on this enhancement in bugzilla?
>
>
>> I can summarize that GMF has its own very special way of handling
>> copy/paste. Given that, it's really not a big help that GMF's clipboard
>
> Yes, the goal of GMF's copy/paste framework is two-fold: to handle more
> complex inter-object dependencies than what can be expressed in Ecore, and
> to serialize copied objects to the system clipboard for copy/paste across
> editing domains or even Eclipse instances.
>
>
>> docs forward to the EMF clipboard docs. From my own experience, I know
>> copy/paste is a very complicated thing, especially when there's a
>> graphical and a semantic model. But some piece of documentation how the
>> specific GMF stuff is meant to work - and how it could possibly be
>> extended - would be very appreciated.
>
> Yes, GMF's extensible copy/paste documentation so far basically consists of
> an example plug-in for the "EXTLibrary" example model from EMF:
> org.eclipse.gmf.examples.runtime.emf.clipboard. As you seem to be
> exploring the clipboard framework in detail, you might be in a good
> position to contribute to the documentation! ;-)
>
>
>> Regards
>> Jan
>>
>> Christian W. Damus schrieb:
>>> Hi, Jan,
>>>
>>> See some replies in-line, below.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>> Jan Köhnlein wrote:
>>>
>>>> Hi,
>>>>
>>>> How do I prevent (non-containment) EReferences from being copied to the
>>>> clipboard?
>>>>
>>>> In my diagram, connections are attached to side affixed children of the
>>>> nodes rather than to the nodes themselves. These child nodes are
>>>> contained elements in the semantic model.
>>>>
>>>> So the ecore model looks like
>>>> TopNodeElement <>--- ChildElement <----------------> ConnectionElement
>>>> children* source 1 outConn 0..1
>>>>
>>>> When I copy a top node with a connected child, the semantic model
>>>> section of the clipboard string roughly looks like
>>>>
>>>> ...
>>>> <TopNode>
>>>> <children xmi:type="ChildNode".../>
>>>> <outConn xmi:type="ConnectionElement".../>
>>>> ...
>>>>
>>>> even though the connection has not been selected. Pasting this, results
>>>> in the connection element being reconnected to the clone, as the
>>>> EReference source (the eOpposite of outConn) has multiplicity 1.
>>> The default copy/paste implementation should never copy a reference whose
>>> opposite has multiplicity 1, unless the referred object is also being
>>> copied (in which case, the two copied objects would be correctly
>>> associated). This sounds like a bug.
>>>
>>>
>>>> I have already tried to implement my own
>>>> NotationClipboardOperationHelper but it does not make a difference. E.g.
>>> Rather than that, I think you need to create a AbstractClipboardSupport
>>> for your semantic model EPackage, not for the notation model.
>>>
>>>
>>>> the isCopyAlways method is only called on the semantic top node
>>>> element, neither on its child nor on the reference connection.
>>>> Similarly, the collection returned by getExcludedCopyObjects() is only
>>>> taken into account on the top node and child semantic elements, the
>>>> latter is then copied including the buggy reference.
>>> AFIACS, the CopyOperation recursively processes the selected objects to
>>> check for copy-always references. However, in your case, the semantic
>>> model elements are not selected, but referenced by selected objects (the
>>> diagram views). It looks like copy-always isn't being recursively
>>> applied
>>> to objects included by copy-always, which might be a bug. However,
>>> implementing an AbstractClipboardSupport for your semantic model might
>>> fix that.
>>>
>>>
>>>> How do I prevent this EReference from being copied? Must I write my own
>>>> override copy commands, or am I missing something?
>>>>
>>>> Regards
>>>> Jan.
>
|
|
|
Goto Forum:
Current Time: Sat Apr 27 00:48:42 GMT 2024
Powered by FUDForum. Page generated in 0.03485 seconds |
] 
Search
Help
Register
Login
Home
