View Issue Details

IDProjectCategoryView StatusLast Update
0016245ScribusScripterpublic2020-09-17 05:59
Reporterale Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionopen 
Product Version1.5.6.svn 
Target VersionFixed in Version 
Summary0016245: in the scripter copyObject can copy one single item at a time
Descriptionthe docstring says that it can also copy a "selection Group" but does not specify what a selection group is.

anyway, i don't see a valid reason why the UI can copy multiple items and the scripter only one...
TagsNo tags attached.
PatchNo

Activities

jghali

2020-09-16 21:08

administrator   ~0048080

Last edited: 2020-09-16 21:08

View 2 revisions

I was mentioning the same issue to Craig yesterday about duplicateObject(). I don't see why copyObject() and duplicateObject() would copy a single object even if selection has multiple objects selected. To fix this, should we just keep copyObject() and duplicateObject() as is for backward compatibility and add new methods like copyObjects() / duplicateObjects() or copySelection() / duplicateSelection(), or just fix copyObject() and duplicateObject() to make them work on current selection ?

utnik

2020-09-16 22:00

updater   ~0048081

i don't think that two different commands are better than one! i'm not a coder, but as a simple user i would prefer to have 'copyObject()' and 'duplicateObject()' fixed.

ale

2020-09-17 05:59

manager   ~0048082

i don't think there is a need for two commands.

since it's "hard" to tell which is the first item in a selection, i don't think there is anyone relying on this behavior to copy only one item instead of all the ones in the selection.
and i don't see a use case for having both functions in the API.

copyObject() is a new command and there should be any big risk of breaking old scripts.

we could think of renaming to xxxObjects() and deprecate the old names, but i generally have an issue with the usage of Frame, Item, and Object in the scripter API (on top of the fact that commands have or not an s at the end) and i think that in the foreseeable future, we should go through all affected commands and find a common naming.
(and, IMO, the term Object should disappear from the API since it's not used in the scribus UI)

all in all: for now, i suggest to leave the name as is. and "silently" change the behavior of the function (it should be mentioned in the release notes, though... but there are so many changes in the scripter API...)

Issue History

Date Modified Username Field Change
2020-09-16 19:53 ale New Issue
2020-09-16 21:08 jghali Note Added: 0048080
2020-09-16 21:08 jghali Note Edited: 0048080 View Revisions
2020-09-16 22:00 utnik Note Added: 0048081
2020-09-17 05:59 ale Note Added: 0048082