[Kst] Concerns with current copy implementation

Andrew Walker arwalker at sumusltd.com
Wed Jan 12 00:16:06 CET 2005

1) This isn't implemented yet. Copy and Paste would obviously
not use the same functions as the menu item Copy.
2) It depends on _parent as we have to set _parent. Once _parent
is removed it can be removed here too.
3) DnD would be much the same as Copy and Paste.
4) The "action" copy was never used, but if its going to be we can
easily create a new method for the current copyObject()
5) Don't think I agree with this.
6) This seems to repeat 1)

The current implementation does what I set out to do. Make a quick
copy of a plot which can then be moved to the desired location.
As ever, once a new feature is in there are numerous proposals to
how it could be better and/or bigger. My plan (as mentioned in the
original bug report) was to also add Copy/Paste and DnD. This remains
to be done and so the bug remains open (96256).

-----Original Message-----
From: George Staikos [mailto:staikos at kde.org]
Sent: Tuesday, January 11, 2005 2:38 PM
To: kst at kde.org
Subject: [Kst] Concerns with current copy implementation

I'm a bit concerned about the design/implementation of the current copy
It's good that it's in layout mode now, but I think the architecture is a
off.  Here's why:

1) Copy&Paste is not usable with the new functions added since they
immediately do the copy and paste.
2) It depends too heavily on _parent, which we're trying to remove.  It can
implemented efficiently without it.
3) It would be useful for DnD too if implemented differently (as I
something like KstViewObjectPtr duplicate() const;)
4) It mixes the "action" copy with the concept of copying a view object,
is abstract and reusable elsewhere.
5) Copy as an action should be toplevel.  There's no need to propagate it
lower.  Only duplication of object properties is object-implementation
specific.  I think Copy is a KstTopLevelView/KstViewWindow/KstApp action.
6) We actually need something more abstract for the concept of "copying"
we sometimes don't want to create objects or duplicate until the "paste"
happens.  This is particularly the case for DnD and traditional Copy+Paste.
Also useful for Undo/Redo I think.  This is why KstViewObjects have the
byte-stream encoding mechanism, and I think this is probably the proper way
to implement all of this stuff.

George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/
Kst mailing list
Kst at kde.org

More information about the Kst mailing list