View Issue Details

IDProjectCategoryView StatusLast Update
0003784ScribusGeneralpublic2006-11-04 23:35
Reporterchristoph_s Assigned Tofschmid  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Platformx86OSLinuxOS VersionSuSE 9.3
Product Version1.3.3.1 
Fixed in Version1.3.4cvs 
Summary0003784: Value for groups of rotated objects is always zero degrees.
DescriptionIf a group of objects is rotated, the properties palette always shows a rotation of zero. After ungrouping, the correct rotation of single objects is displayed.
TagsNo tags attached.
Patch

Relationships

related to 0003608 closedfschmid resize errors with groups of rotated objects 
related to 0003792 closedfschmid wrong rotation displayed for group when changing properties 
child of 0003812 acknowledged Metabug: Grouped objects 

Activities

mkoren

2006-05-09 23:49

reporter   ~0011190

I think I've noticed that. But is there always a correct value to display for the group? E.g. in a group of two frames rotated different amounts. This semantic distinction is why I had thought maybe transformations that aren't remembered should be moved to a separate location from those that set specific frame properties, as I said in 0003642. What do people think?

In that case the persistent rotation field would be blanked and disabled for a group, and rotations applied via a separate tool of some kind.

christoph_s

2006-05-09 23:56

developer   ~0011192

Last edited: 2006-05-09 23:56

If a group is rotated, it is rotated by a number of degrees, independent of the rotation of single objects. Therefore, the rotation of the group needs to displayed in the properties palette. You can rotate individual objects only after ungrouping, so their rotation in the group is irrelevant.

mkoren

2006-05-10 00:09

reporter   ~0011193

I don't think groups have that strong of an "identity" in the current implementation. (They would in some of my proposals.) I.e., nothing internally "remembers" the original state of a group when it was created to compare its current rotation to.

After rotating a group the selection bounding box changes shape; it doesn't display as rotated, and since groups don't (at the moment) have frames, there's really no meaning to the "rotation" of a group as I see it. Hence group rotation is a one-time transformation, not a persistent property.

christoph_s

2006-05-10 00:56

developer   ~0011194

Last edited: 2006-05-10 00:58

>>>I don't think groups have that strong of an "identity" in the current implementation. (They would in some of my proposals.) I.e., nothing internally "remembers" the original state of a group when it was created to compare its current rotation to.

IOW, as long as your feature requests aren't implemented, this is not a bug (sorry, couldn't resist). ;)

>>>After rotating a group the selection bounding box changes shape; it doesn't display as rotated, and since groups don't (at the moment) have frames, there's really no meaning to the "rotation" of a group as I see it. Hence group rotation is a one-time transformation, not a persistent property.

So how do you handle a group of objects that has been rotated 32 degrees, and you want a rotation of 34,5 instead? You have to remember the original rotation and add the difference. That's no reasonable way of handling things.

mkoren, Scribus is not a CAD software ;)

mhanski

2006-05-10 13:58

developer   ~0011200

confirmed with 1.3.3.1 on win2000

mkoren

2006-05-10 16:59

reporter   ~0011205

I agree; without my proposals this is not a bug. ;) (0003792, on the other hand, is.)

I'm not saying that's how it should be, just how it is. From looking at the group representation in an sla file, I think a group's only identity is as a number listed in the XML description of each item that's in it; it doesn't have any properties of its own.

The current implementation has its logic: consider a group of objects all at different individual rotations. What is the correct "zero" rotation axis for the group as a whole? If the group is rotated 30 degrees, then ungrouped and grouped again, should the rotation of the new group now be set to zero at the new orientation? Any data specific to the old group can't possibly be remembered.

What you want is groups with their own coordinate system, that behave more like individual objects, and I agree. But that's a feature request. (And for the record, CAD programs are the only things I've seen with this feature, though did I mention them here? ;)

christoph_s

2006-05-10 17:13

developer   ~0011206

>>>From looking at the group representation in an sla file, I think a group's only identity is as a number listed in the XML description of each item that's in it; it doesn't have any properties of its own.

Absolutely irrelevant from a user's point of view.

>>>The current implementation has its logic: consider a group of objects all at different individual rotations. What is the correct "zero" rotation axis for the group as a whole?

You have noticed there is virtual rectangular frame drawn around a group?

>>>If the group is rotated 30 degrees, then ungrouped

... it's no longer a group ;)

>>>and grouped again, should the rotation of the new group now be set to zero at the new orientation

Yes, because it's a new group.

mkoren, have you ever been part of a real DTP workflow? That's what people do everyday and how they expect it to be, no matter if it fits the "theory" better.

mkoren

2006-05-10 17:22

reporter   ~0011207

Christoph, I _agree_ with you, all I'm saying is it will take an entirely new implementation of groups to do it, closer to what I've asked for already.

christoph_s

2006-11-04 23:35

developer   ~0013275

Tested. Fixed.

Issue History

Date Modified Username Field Change
2006-05-09 22:59 christoph_s New Issue
2006-05-09 23:00 christoph_s Relationship added related to 0003608
2006-05-09 23:49 mkoren Note Added: 0011190
2006-05-09 23:56 christoph_s Note Added: 0011192
2006-05-09 23:56 christoph_s Note Edited: 0011192
2006-05-10 00:09 mkoren Note Added: 0011193
2006-05-10 00:56 christoph_s Note Added: 0011194
2006-05-10 00:58 christoph_s Note Edited: 0011194
2006-05-10 13:58 mhanski Note Added: 0011200
2006-05-10 13:58 mhanski Status new => confirmed
2006-05-10 16:59 mkoren Note Added: 0011205
2006-05-10 17:13 christoph_s Note Added: 0011206
2006-05-10 17:22 mkoren Note Added: 0011207
2006-05-12 23:13 christoph_s Relationship added related to 0003792
2006-05-13 16:48 christoph_s Relationship added related to 0003812
2006-05-13 16:49 christoph_s Relationship deleted related to 0003812
2006-05-13 16:49 christoph_s Relationship added child of 0003812
2006-11-02 22:52 cbradney Status confirmed => assigned
2006-11-02 22:52 cbradney Assigned To => fschmid
2006-11-02 22:52 cbradney Status assigned => resolved
2006-11-02 22:52 cbradney Fixed in Version => 1.3.4cvs
2006-11-02 22:52 cbradney Resolution open => fixed
2006-11-04 23:35 christoph_s Status resolved => closed
2006-11-04 23:35 christoph_s Note Added: 0013275