unexplainable behavior when copying and pasting symbol, not dragging

[Alvin Penner]

- Windows XP, Inkscape rev 13638
- open Inkscape, open Symbols Dialog
- draw ellipse or whatever
- in Symbols dialog, click on 'Add Symbol' icon
- in main window, delete original object, just to simplify matters
- save as symbol_org.svg, attached here
- the file should now consist of a single <symbol> element, symbol7263, in the <defs> section, and nothing in Layer 1.

[Alvin Penner (apenner)]

- before doing the copy and paste it is probably a good idea to confirm that the current layer is still Layer 1, not root.
- now click on the symbol element in the Symbols dialog, to highlight it
- hit ctrl-C to copy
- with left mouse button, click on the main window to put the focus there, which will deselect the symbol in the Symbols dialog
- use the right mouse button to Paste into the main window
- save as symbol_paste.svg

- at this point we expect a visible symbol in the main window, but there is none.
- if we interrogate the XML editor we find a new <symbol> element in Layer 1, which is not visible.
- underneath it in the XML editor is a <ellipse> element. If we click on the <ellipse> element in the XML editor, then a dotted rectangle becomes visible in the main window, but the ellipse itself is invisible.

- depending on the exact sequence of events, for example if you load the file symbol_paste.svg by itself, you may find that there are two symbols showing in the Symbol Dialog, even though the defs section indicates only one symbol.

Note that a drag and drop operation from the Symbol Dialog works normally. It creates a new <use> element in Layer 1, which is visible.

- Symbols dialog does not exist in Inkscape 0.48.5 so nothing to compare to

[su_v (suv-lp)]

@doctormo - any chance you could take a closer look at this report? IIRC the new feature which allows to directly select (hidden) objects stored in the <defs> section in a docked dialog was implemented by you?

[su_v (suv-lp)]

On 2014-10-27 22:24 (+0200), Alvin Penner wrote:
> - if we interrogate the XML editor we find a new <symbol> element in Layer 1, which is not visible.
> - underneath it in the XML editor is a <ellipse> element. If we click on the <ellipse> element in the XML editor, then a dotted rectangle becomes visible in the main window, but the ellipse itself is invisible.

AFAIU this is correct rendering: the symbol definition <symbol> in SVG (which is currently pasted from the clipboard when copying an object selected in the symbols dialog) is not to be rendered visibly, only instances of a <symbol> via <use> (aka clones) are [1].

It seems to me that with the new feature for symbols (drag&drop to create instances on the canvas), explicitly copying the current selection to the clipboard should be disabled (or warn the user that what is actually copied is the definition, not an instance) if the current selection is an element from the <defs> section in the 'Symbols' dialog and the 'Symbols' dialog has the focus.

@Alvin: simply selecting an object in the 'Symbols' dialog already puts an instance of the symbol on the clipboard which can be pasted onto the canvas (alternatively to using drag&drop).

On 2014-10-27 22:24 (+0200), Alvin Penner wrote:
> - depending on the exact sequence of events, for example if you load the
> file symbol_paste.svg by itself, you may find that there are two symbols
> showing in the Symbol Dialog, even though the defs section indicates
> only one symbol.

AFAIU to be expected: the dialog lists all symbols defined in the current document (as described in the 'Symbol set' selector), and in SVG 1.1, symbol definitions can happen anywhere in the document (because they are not rendered visible no matter what).

--
[1] http://www.w3.org/TR/SVG11/struct.html#SymbolElement

[su_v (suv-lp)]

Reproduced with 0.91pre2 r13630 and current trunk r13638 on OS X 10.7.5.

[Alvin Penner (apenner)]

thanks for the info. I got the copy and paste to work properly, as you suggested , by simply clicking on the symbol and then pasting it.

However I guess that leads into the next question, which is, why would it ever be considered to be desirable to actually have such behavior? This is extremely non-intuitive. I cannot think of any other application or instance in which a simple selection of an object would lead to an automatic copy operation. The gui gives no indication that this has occurred. And after the first paste operation the symbol is deselected automatically which strongly suggests that the paste has now been disabled and yet it has not been disabled, it still works. There is zero feedback here to indicate to the user what is going on. With no feedback the best thing to do would be a "normal" copy and paste behavior, which this is not. (sorry for venting, its been a long day....)

[su_v (suv-lp)]

On 2014-10-27 22:24 (+0100), Alvin Penner wrote:
> - Symbols dialog does not exist in Inkscape 0.48.5 so nothing to
> compare to

Original implementation of the Symbols dialog: rev 11782
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/11782>

Add drag&drop to canvas support: rev 11880
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/11880>

Based on tests with archived builds, the reported inconsistency (pasting a symbol explicitly copied in the 'Symbols' dialog inserts a copy of symbol definition itself instead of an instance of the symbol (i.e. a <use> element aka clone)) started with rev 12374 (not reproduced with rev 12473):
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12374>

[Martin Owens (doctormo)]

I'm not sure it is a bug if the item contents can be copied and pasted. It sounds like a really useful feature, especially for some of the items that could do with copying rather than cloning.

Is there a UX error? Maybe we can walk through the workflow and find a better way to present it.

[Alvin Penner (apenner)]

at the risk of perhaps beating a dead horse, there are two rules here that are absolutely mandatory and cannot be broken:

the first rule is that the outcome of a copy operation should be unique despite the fact that there may have been multiple possible ways of actually triggering the copy

the second rule is that the outcome of a copy and paste operation should be identical to a drag and drop operation.

both of these rules have been broken.

[Martin Owens (doctormo)]

You have stated the rules (which is useful), but not why. The proposed issue if fixed would remove functionality without recourse.

[su_v (suv-lp)]

IMvHO the underlying issue with the current UX is more serious and even risks actual loss of data without informing/warning the user accordingly. As far as I understand the problem is not specifically that the user can actually paste a symbol definition onto the canvas itself (quite useless btw, since such symbol definitions scattered among regular objects in the current layer are not accessible with regular canvas tools (<symbol> elements render not visibly by definition, not even in Inkscape's outline view)). The actual problem is that the current implementation of the symbol dialog actually selects elements normally not given access to; and does accept keyboard shortcuts for various commands which act on the selected elements in the <defs> section directly, without any information or notification of the user at all.

Scenario for loss of data:
1) create a symbol
2) add several instances on-canvas
3) in the symbols dialog, select the symbol (in 'Current Document')
4) while focus is still in the symbols dialog, type 'Shift+G'

Result:
The selected object (the symbol definition in the <defs> section) is converted into guides (as applicable), and removed from the <defs> section (with default prefs, converting to guides deletes the object itself). All instances of the symbol on-canvas are unlinked and replaced with a copy of the original symbol (this is what I consider as loss of data, since it can't be "reversed" or undone later on). The icon view of the existing symbols in the current document is not refreshed -> the user has no possible way to quickly notice what just had happened (unless forcing a regeneration of the icon view by temporarily switching to a different symbol library and back to 'Current Document' again). Any data loss (symbol instances replaced with static copies) is likely only noticed when reopening the document in a later session (the lost data cannot be recovered anymore).

IMvHO this implementation is troublesome UX, because it hides from the user what it does (commands intended to work on (visible) selections on-canvas are applied unfiltered to (hidden) elements selected in the <defs> section). 'Ctrl+C', 'Ctrl+G', 'Shift+G' are just examples; generally it would seem reasonable that none of the regular keyboard shortcuts are allowed to interact with a selected symbol icon of the current document. Or the interface to manage symbols in the current document needs to be changed back to a basic icon view without employing the same kind of 'selection' mechanism as used for canvas objects.

On a side note, it should also not be allowed to apply 'Add Symbol from the current document' to a symbol icon (i.e. the symbol definition in the <defs> section) selected in the dialog. Currently, that adds a <use> element inside the <defs> section - not visible nor usable otherwise.

[Martin Owens (doctormo)]

There is certainly a case to be made for keyboard commands.

Although I'd be sad to increase the code by hundreds of lines to reduce and remove functionality. Overall the UX is fine and does more expected things than non-expected things.

I'd be interested to set up a ux test though, so we're not just proffering honest opinions without some data to work from.