View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0010255||Scribus||Graphics / Image Frames||public||2011-09-10 04:15||2016-05-06 01:13|
|Platform||x86 Fam 6 Mod 8 Stepping||OS||M$ Win 2000 SP4||OS Version||5.00.2195|
|Summary||0010255: groups involved in temporary "select-copy-paste" maneuver erroneously super-grouped|
|Description||At times, after temporarily selecting objects which are|
themselves groups, for cloning for another instance in "copy-paste,"
the association (NOT "grouping") turns out not to have been temporary
but acts partially as a super-group object. Later on, upon selecting
just one such involved first-level object, others that were
"select-copy-pasted" appear in an unintended GROUP.
It's as if Bug 0010183 were incompletely implemented--not cleaning up
the supposed temporary grouping for re-instancing the selection,
which was never declared a "group" by user. Some groups have been
dissociated, others not.
Attempting recovery by "ungroup" operation on the wrongly grouped objects
is seldom successful. Rather, it destroys the grouped nature of the
several objects involved in the select-copy-paste maneuver.
Big time-waster when it happens. Happens so seldom I cannot characterize
what is special about the instances that get into trouble. Seemed to have
been fixed at 1.4.0_rc4, but popped up again, and persists in rc5.
Looks like incomplete understanding of the object grouping
database, or vague design of its methods. How about a separate
database for "select-copy-paste," absolutely apart from
intentional grouping? Blow away the db completely upon
each multi-object selection, for a clean start and clean
|Steps To Reproduce||Group several objects. |
Form several such groups.
Select them together.
Copy. Paste. Cancel selection.
Go on to other things for awhile.
Select just one of the original groups or a clone of such.
Do this dozens of times.
Note sometimes that the singly selected, supposedly autonomous, object
(a group) is now associated with another in a "group" that was not intended.
Try "ungrouping." Fail to dissociate the one-time selection, but note
that the object itself has been ungrouped.
|Additional Information||I could send a file containing an instance, with a rather labored description of|
what to look for. I am preparing sheet music, with hundreds of notes per page.
taters-maters-bugdemo.sla (1,589,098 bytes)
The 'notes' on the lower half of page 1 are from a select operation on just the first of the three lines on the upper half-page. Note that the ligatures ('ties'; 'slurs') also present on the lower half were not in the selection rectangle, but nevertheless appeared highlighted (see their originals in the second and third lines in upper half-page) along with the intended selection. That is, the lower half of the page was unpopulated with notes before the copy-paste.
All ligatures on the page, regardless of present size, are copy-paste descendents of a single object from a library of furniture (separate file), added after the ligand notes are in place.
||FirasH, jghali, can you reproduce ?|
|2011-09-10 04:15||slantnote||New Issue|
|2011-09-10 06:47||slantnote||File Added: taters-maters-bugdemo.sla|
|2011-09-10 07:00||slantnote||Note Added: 0026845|
|2015-05-21 12:46||Kunda||Relationship added||child of 0003812|
|2015-09-17 20:10||Kunda||Category||Graphics / Image Frames => Graphics/Img Frames|
|2015-09-17 20:11||Kunda||Category||Graphics/Img Frames => Graphics / Image Frames|
|2015-12-02 12:22||Kunda||Relationship added||related to 0010183|
|2015-12-02 12:22||Kunda||Patch||=> No|
|2015-12-02 12:22||Kunda||Description Updated|
|2015-12-02 12:24||Kunda||Tag Attached: #please_test|
|2016-05-05 18:11||Kunda||Tag Attached: discussion|
|2016-05-06 01:13||Kunda||Note Added: 0040807|