It seems like when copying to the clipboard, there needs to be a mechanism to scan the selected objects for any referenced objects and also copy the defs for those. The recipient of the paste would then need to add those refs to its own set of defs. It's possible that the receiving document could a) have a different def by the same name, or b) have the same def by a different name; in case (a) it would seem prudent to rename the incoming style, and in case (b) perhaps it should normally merge by default but allow the user an option to not merge when pasting.
That sounds like a lot of code. Maybe we can simplify it a bit as follows:
- a new clipboard is made for storing defs
- whenever anything is cut or copied, the entire defs from the current document are placed on that defs clipboard
- whenever clipboard objects (or style) are pasted, the contents of the defs clipboard are merged with the current document defs:
-- same name, same content: disregard
-- same name, different content: rename both defs and the pasted objects' references (this is the most tricky part)
-- different name, same content: just add, no merge
An advantage of this approach is that you don't need to scan your objects and select relevant defs when copying. However, you'll still have to scan and re-id what you are pasting in case of name conflicts (although these are likely to be rare).
On Sun, 30 Nov 2003, bulia byak wrote:
It seems like when copying to the clipboard, there needs to be a mechanism to scan the selected objects for any referenced objects and also copy the defs for those. The recipient of the paste would then need to add those refs to its own set of defs. It's possible that the receiving document could a) have a different def by the same name, or b) have the same def by a different name; in case (a) it would seem prudent to rename the incoming style, and in case (b) perhaps it should normally merge by default but allow the user an option to not merge when pasting.
That sounds like a lot of code. Maybe we can simplify it a bit as follows:
a new clipboard is made for storing defs
whenever anything is cut or copied, the entire defs from the
current document are placed on that defs clipboard
You know, this approach also occurred to me, but since you'd specified 'eligant' I didn't mention it. I agree it'd be simpler in the short term, but I'd be worried it could get out of hand, as if you start copying from document to document your defs section could get bloated. There may be ways around it, such as dynamic garbage collection of unreferenced def's, etc. so maybe it'd be doable.
Also, conceptually if you're just copying a small bit of a very huge and complex drawing with lots of defs, it would seem most efficient to just carry the pieces of the original actually needed, and not fill the clipboard with a bunch of irrelevant stuff. On the other hand, I'm probably over-worrying about optimization here; this is certainly something that could be easily refactored down the road if we find it taxes resources.
Anyway, so yeah that simplification is probably okay, and it sounds like it'd be a lot quicker to code that way. We will definitely need to keep an eye on the defs though.
- whenever clipboard objects (or style) are pasted, the contents of
the defs clipboard are merged with the current document defs:
-- same name, same content: disregard
-- same name, different content: rename both defs and the pasted objects' references (this is the most tricky part)
-- different name, same content: just add, no merge
An advantage of this approach is that you don't need to scan your objects and select relevant defs when copying. However, you'll still have to scan and re-id what you are pasting in case of name conflicts (although these are likely to be rare).
*Nod* This'll work, especially since a user can easily go in through the XML editor (or even a text editor) and cleanup the document if the merge doesn't work smartly enough.
Bryce
participants (2)
-
Bryce Harrington -
bulia byak