View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003784 | Scribus | General | public | 2006-05-09 22:59 | 2006-11-04 23:35 |
| Reporter | christoph_s | Assigned To | fschmid | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | x86 | OS | Linux | OS Version | SuSE 9.3 |
| Product Version | 1.3.3.1 | ||||
| Fixed in Version | 1.3.4cvs | ||||
| Summary | 0003784: Value for groups of rotated objects is always zero degrees. | ||||
| Description | If 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. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
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. |
|
|
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. |
|
|
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. |
|
|
>>>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 ;) |
|
|
confirmed with 1.3.3.1 on win2000 |
|
|
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? ;) |
|
|
>>>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. |
|
|
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. |
|
|
Tested. Fixed. |
| 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 |
