Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » Some small issues with Copy/Paste
Some small issues with Copy/Paste [message #737250] Fri, 14 October 2011 20:51 Go to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 181
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
I've playing a little with Copy/Paste features. The basic support is quite nice and ingenuous. Some issues/observations:


1. The tutorial seems to assume that one will do just a cloning of the pictogram but not of the Business object. It should be clear that this is not necesary (I'm not even sure it's typical), one could also want to clone the business object.

2. The copy/paste inner working does quite dark magic (for me, at least) to place an EObject in the SWT clipboard, using the URIs of the EObjects (I would have expected something simpler, more like an serialization/deserialization, but I don't kwnow anything about SWT clipboard, and little about EMF).
This has some hidden implicancies: one must not copied pre-cloned detached objects, for example. Further, perhaps the tutorial (or the javaDocs) should mention that the canXXXX() methods in the Features should be as light as possible, in particular the canPaste() method is called a lot.

3. Because of that dark magic (I guess) the type of the content placed in the clipboard seems to confuse the rest of the workbench. For example, if I copy a graphical element (in the tutorial) and go to the Project Explorer, the "paste" menu is enabled - this is slightly incorrect, compare with what happens when one copies some text in a text editor.

4. For simplicity, the tutorial places the paste objects at the origin. I tried the more typical behaviour, placing the objects at some fixed offset from the original elements. It basically worked, but it revealed a little issue: if several objects were involved, only one of the new objects is selected after the paste. This is atypical and frustrating, because one frequently wants to move together the set of cloned objects.
Should I enter a bug?

BTW: Is there some programmatic way of marking some pictograms as selected?

5. Another user-unfriendly thing of the tutorial, is the bit about disabling the paste if some element apart from the diagram is selected. The user typically selects some elements, type Ctrl-C, Ctrl-V in sucession, and expects that the selected elements are cloned. Of course, this can be just an idiosincracy of the tutorial, but I wonder why it was implemented in that way.

[Updated on: Fri, 14 October 2011 20:52]

Report message to a moderator

Re: Some small issues with Copy/Paste [message #741181 is a reply to message #737250] Wed, 19 October 2011 09:04 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1635
Registered: July 2009
Location: Walldorf, Germany
Senior Member
See my comments below.

Michael


"Hernan" schrieb im Newsbeitrag news:j7a6m0$t3g$1@news.eclipse.org...

I've playing a little with Copy/Paste features. The basic support is quite
nice and ingenuous. Some issues/observations:


1. The tutorial seems to assume that one will do just a cloning of the
pictogram but not of the Business object. It should be clear that this is
not necesary (I'm not even sure it's typical), one could also want to clone
the business object.

Michael: I added a note in the Copy&Paste section of the tutorial on that.


2. The copy/paste inner working does quite dark magic (for me, at least) to
place an EObject in the SWT clipboard, using the URIs of the EObjects (I
would have expected something simpler, more like an
serialization/deserialization, but I don't kwnow anything about SWT
clipboard, and little about EMF).
This has some hidden implicancies: one must not copied pre-cloned detached
objects, for example. Further, perhaps the tutorial (or the javaDocs) should
mention that the canXXXX() methods in the Features should be as light as
possible, in particular the canPaste() method is called a lot.

Michael: Hm, the way the clipboard is implement was simply taken over from
our previous implementation on our MOF-based modeling infrastructure. There
it was natural to implement it like this. Maybe in EMF a different
implementation would make sense, not sure about that.
Regarding the performance of the canXXX methods I added a note to the docu
page.


3. Because of that dark magic (I guess) the type of the content placed in
the clipboard seems to confuse the rest of the workbench. For example, if I
copy a graphical element (in the tutorial) and go to the Project Explorer,
the "paste" menu is enabled - this is slightly incorrect, compare with what
happens when one copies some text in a text editor.

Michael: Hm, you're right. What happens is a little irritating; would you
open a bugzilla for this?


4. For simplicity, the tutorial places the paste objects at the origin. I
tried the more typical behaviour, placing the objects at some offset from
the original. It basically worked, but it revealed a little issue: if
several objects were involved, only one of the new objects is selected after
the paste. This is atypical and frustrating, because one frequently wants to
move together the set of cloned objects.
Should I enter a bug?

Michael: For M3 we enhanced the paste context with the location information,
so users can also paste their stuff to the mouse location. The tutorial
shows how to do that. Selecting objects after feature processing is always
restricted to at most one object. An enhancement request should target that
completely; feel free to open one.


BTW: Is there some programmatic way of marking some pictograms as selected?

Michael: you can select them in the editor:
DiagramEditor.selectPictogramElements(PictogramElement[] pictogramElements)


5. Another user-unfriendly thing of the tutorial, is the bit about disabling
the paste if some element apart from the diagram is selected. The user
typically selects some elements, type Ctrl-C, Ctrl-V in sucession, and
expects that the selected elements are cloned. Of course, this can be just
an idiosincracy of the tutorial, but I wonder why it was implemented in that
way.

Michael: This is just the way it is implemented in the tutorial for showing
how to restrict copy and paste, without having much focus on usability.
Re: Some small issues with Copy/Paste [message #741463 is a reply to message #741181] Wed, 19 October 2011 15:00 Go to previous message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 181
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
Michael Wenz wrote on Wed, 19 October 2011 06:04

Michael: Hm, the way the clipboard is implement was simply taken over from
our previous implementation on our MOF-based modeling infrastructure. There
it was natural to implement it like this. Maybe in EMF a different
implementation would make sense, not sure about that.



Some related material that might be useful/inspirational... in some distant future Razz

http://esalagea.wordpress.com/2011/04/13/lets-solve-once-for-all-the-gmf-copy-paste-problem-and-then-forget-about-it/

http://rtsys.informatik.uni-kiel.de/trac/kieler/wiki/Help/GmfCookbook/CutCopyPaste

(It seems to me, from a very cursory read, that the proposal implements its own clipboard)

Quote:


Michael: Hm, you're right. What happens is a little irritating; would you
open a bugzilla for this?


Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=361414

Quote:


Michael: For M3 we enhanced the paste context with the location information,
so users can also paste their stuff to the mouse location. The tutorial
shows how to do that. Selecting objects after feature processing is always
restricted to at most one object. An enhancement request should target that
completely; feel free to open one.


Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=361416

Thanks
Previous Topic:Using Graphiti with an emf based model
Next Topic:Restricting move
Goto Forum:
  


Current Time: Sat Nov 22 03:14:03 GMT 2014

Powered by FUDForum. Page generated in 0.03195 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software