|
|
| Re: Copy and Paste does not cater for transient children [message #187598 is a reply to message #187525] |
Sun, 18 May 2008 18:49   |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Kristian,
I would expect that copy/paste in canonical diagrams should only copy
the semantic elements. Canonical views, by definition, are always
created on-the-fly by the diagram editor from the semantics, which
applies as well to the paste target as to the source of the copy
operation.
If you have ordering dependencies between persisted and transient
views, then probably it will be necessary for you to persist all of
these views. Then, copy/paste possibly wouldn't have an issue, anyway.
If you are finding that transient views are being copied, then that is
probably a bug, and should be raised in the GMF bugzilla. If you
attach your patch, too, then that should give the GMF team a boost.
HTH,
Christian
On Friday 05-16-2008 (11:27), Kristian O'Connor wrote:
> Note - the cast to a Node in the solution should be a cast to a View!
> "Kristian O'Connor" <kristian.oconnor@gmail.com> wrote in message
> news:g0jq2t$kn$1@build.eclipse.org...
>> Hi all -
>> This refers to the notational model copy and paste...
>> It looks like the copy and paste code relies heavily on the
>> presistedChildren to be functional, from a previous thread with Alex
>> Shatalin we cannot
>> guarantee that the persisted children actually exist.. ie the
>> diagram may be new and populated
>> with transientChildren only.
>> This issue only affects diagrams where order is important.. for
>> example.. A container view with many children!
>> Think bookshelf with some ordered (left to right) books on it!!
>> If the diagram is created with say 5 children (books) in a
>> container (bookshelf) the canonical editpolicy will create
>> the views as transient children... a copy and paste into that
>> container will use the persisted children
>> (which is empty) to add the pasted element(s). Therefore you end
>> up with the pasted elements being in
>> the persisted elements list and all the others existing in the
>> transient list, if order is important then you
>> are left in a bit of a pickle :o)
>> see
>> org.eclipse.gmf.runtime.emf.clipboard.core.PasteChildOperati on#doPast
>> eInto(..)
>> The solution I came up with is attached... solution.txt
>> Does someone have any insight into this issue...? is it a know
>> bug? should I create a new bug in
>> bugzilla and supply a patch file solution...
>> Thanks in advance,
>> Kristian
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
|
|
|
| Re: Copy and Paste does not cater for transient children [message #187965 is a reply to message #187598] |
Tue, 20 May 2008 13:59 |
 Kristian O'Connor
Messages: 29
Registered: July 2009 |
Junior Member |
|
|
Hi, Christian
I am no expert on what is going on with copy and paste but I'll try to
explain
myself... :o)
The reason the children are not persisted is that the diagram is newly
created,
the ViewService creates the notational resource with the diagram views
marked as transient... to my knowledge anyhows.. rather to knowledge gained
from Alex S.
The copy in the GMF world copies the Notational part to my knowledge...
ie. the Views and pastes them into Views.
Views being EObjects can be defined (I guess) as the semantical parts
of a Notational Diagram. I hope that makes sense!
Transient views are not being copied - rather the view that was copied
cannot be pasted into a Transient view... best way to think here is
copying from one instance of a diagram editor and pasting into a newly
intialized instance of a diagram editor...
The problem really concerns only these newly initialised diagrams...
I have no problem in creating a bugzilla report and patch if this issue
proves to warrent one :o)
Thanks for your initial reply.
Regards
Kristian.
"Christian W. Damus" <cdamus@zeligsoft.com> wrote in message
news:nemoSun051808024513@news.eclipse.org...
> Hi, Kristian,
>
> I would expect that copy/paste in canonical diagrams should only copy
> the semantic elements. Canonical views, by definition, are always
> created on-the-fly by the diagram editor from the semantics, which
> applies as well to the paste target as to the source of the copy
> operation.
>
> If you have ordering dependencies between persisted and transient
> views, then probably it will be necessary for you to persist all of
> these views. Then, copy/paste possibly wouldn't have an issue, anyway.
>
> If you are finding that transient views are being copied, then that is
> probably a bug, and should be raised in the GMF bugzilla. If you
> attach your patch, too, then that should give the GMF team a boost.
>
> HTH,
>
> Christian
>
> On Friday 05-16-2008 (11:27), Kristian O'Connor wrote:
>> Note - the cast to a Node in the solution should be a cast to a View!
>
>> "Kristian O'Connor" <kristian.oconnor@gmail.com> wrote in message
>> news:g0jq2t$kn$1@build.eclipse.org...
>>> Hi all -
>
>>> This refers to the notational model copy and paste...
>
>>> It looks like the copy and paste code relies heavily on the
>>> presistedChildren to be functional, from a previous thread with Alex
>>> Shatalin we cannot
>>> guarantee that the persisted children actually exist.. ie the
>>> diagram may be new and populated
>>> with transientChildren only.
>
>>> This issue only affects diagrams where order is important.. for
>>> example.. A container view with many children!
>>> Think bookshelf with some ordered (left to right) books on it!!
>
>>> If the diagram is created with say 5 children (books) in a
>>> container (bookshelf) the canonical editpolicy will create
>>> the views as transient children... a copy and paste into that
>>> container will use the persisted children
>>> (which is empty) to add the pasted element(s). Therefore you end
>>> up with the pasted elements being in
>>> the persisted elements list and all the others existing in the
>>> transient list, if order is important then you
>>> are left in a bit of a pickle :o)
>>> see
>
>
>>> org.eclipse.gmf.runtime.emf.clipboard.core.PasteChildOperati on#doPast
>>> eInto(..)
>
>>> The solution I came up with is attached... solution.txt
>
>>> Does someone have any insight into this issue...? is it a know
>>> bug? should I create a new bug in
>>> bugzilla and supply a patch file solution...
>
>>> Thanks in advance,
>>> Kristian
>
>
>
>
>
> --
> I'm trying a new usenet client for Mac, Nemo OS X.
> You can download it at http://www.malcom-mac.com/nemo
>
|
|
|
Powered by
FUDForum. Page generated in 0.03308 seconds
] 
Search
Help
Register
Login
Home
