View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001659 | Scribus | Documentation | public | 2005-02-10 12:55 | 2006-01-22 22:51 |
| Reporter | louisdesjardins | Assigned To | |||
| Priority | normal | Severity | text | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | Linux | OS | Mandrake | OS Version | 10.1 |
| Product Version | 1.2.5cvs | ||||
| Fixed in Version | 1.2.5cvs | ||||
| Summary | 0001659: Editing overlapping frames is very challenging because when selected, a frame retains its stacking order | ||||
| Description | Depending on the stack order of the elements, it can be really unintuitive to try to edit a frame. This is because the frames retain their stacking order even when selected. The expected behaviour would be that the selected frame gets the priority while selected -- thus allowing easy editing -- and gets back to its original stacking order when unselected (when editing is done). | ||||
| Steps To Reproduce | Draw 3 text frames and make them overlap. Select the middle one and try to enlarge it or reduce it with the mouse and handles. When you try grabbing a handle, depending upon where is the handle, it will be very easy or almost impossible to edit. You either have a handle on top of a lower stacked frame, then editing is easy. Or your handle overlaps a frame that in fact is higher stacked, then editing is impossible because as soon as you grab the handle, the higher stacked frame gets selected. Sorry for the bad explanation. Please try it and you'll see exactly what I mean. | ||||
| Additional Information | I think this is a real problem because it prevents free editing of the frames. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
Precision: it prevents easy editing of the frame itself, not the content. So basically what can be found in the X-Y-Z section of the Properties. A very common result of this behaviour is ending up editing unexpectedly the wrong frame, sometimes making it almost disappear (almost!) with a height under a pica... All this depends on the handle you grab. Very difficult to work that way. Actually, it took that long for me to figure out exactly what was causing this. |
|
|
Note from Craig Bradney (picked from the mailing list): The current behaviour works as follows: Control shift select any frame on any level on one layer to select it. Then to move or resize the frame you have selected, hold down control. |
|
|
Louis does the hints given by Craig solve the issue ? |
|
|
Craig made the point this is not a bug and I agree. Once we know how to use the tool, it's useable. It's just difficult to figure out (and I don't think it's documented). For that last reason I think we both agree this needs a little varnishing job in terms of simplicity/usability/documentation. So, we should change this from Major to Feature. Case still open imo. You'll probably want to bump it to 1.3.x |
|
|
I'm taking the bug to make sure this documented. |
|
|
bumping to 1.2.3 |
|
|
Our little circle of DTP experts has just discussed this behaviour and besides the fact that illustrator does it similarly, we couldn't come up with an idea why the behaviour is actually *useful* this way. Lots of people wonder about the somewhat non-intuitive behaviour (and IMHO would do so even if it were documented). |
|
|
I think this confuses and annoys a *lot* of people. It's probably actually a dupe of 0000482. I for one want to see it dead, dead, dead as part of the scribusview fixups. |
|
|
mcornils - any hints what would be ideal ? |
|
|
Craig, Peter, Craig, Sorry to cite myself but considering the latest comments I am back to my original post. I now think we hardly are going to get away from this just with a better explanation in the docs. The behaviour is simply not what we expect and I am not sure this applies only to Quark users. Anyway, here is my 2-cents on this: >>>The expected behaviour would be that the selected frame gets the priority while selected -- thus allowing easy editing -- and gets back to its original stacking order when unselected (when editing is done). |
|
|
I'd tend to agree with louisdesjardins last paragraph. If you have multiple z-layered objects, normally select the first one. Pressing Ctrl while selecting rotates through the z-layered objects. However, when one object among those present is already selected, give that one the focus. |
|
|
its now documented at least |
|
|
Louis, I'm going to close this.. just because. Now that its documented its no longer a bug. I *will* fix this in 1.3.x sometime. Remind me at about 1.3.5 if its not fixed then. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-02-10 12:55 | louisdesjardins | New Issue | |
| 2005-02-10 20:00 | louisdesjardins | Note Added: 0003684 | |
| 2005-04-03 12:34 | louisdesjardins | Note Added: 0004053 | |
| 2005-04-08 07:53 |
|
Note Added: 0004166 | |
| 2005-04-08 12:12 | louisdesjardins | Note Added: 0004184 | |
| 2005-04-08 12:33 |
|
Note Added: 0004185 | |
| 2005-04-08 12:33 |
|
Assigned To | => plinnell |
| 2005-04-08 12:33 |
|
Severity | major => text |
| 2005-04-08 12:33 |
|
Status | new => assigned |
| 2005-04-08 12:33 |
|
Category | General => Documentation |
| 2005-04-08 12:33 |
|
Product Version | 1.2.1 => 1.2.2cvs |
| 2005-05-27 07:26 |
|
Relationship added | has duplicate 0001994 |
| 2005-07-06 11:32 |
|
Note Added: 0005407 | |
| 2005-07-06 11:32 |
|
Product Version | 1.2.2cvs => 1.2.3cvs |
| 2005-07-06 14:09 | mcornils | Note Added: 0005414 | |
| 2005-08-09 16:40 |
|
Relationship added | related to 0000482 |
| 2005-08-09 16:41 |
|
Note Added: 0005991 | |
| 2005-08-10 11:25 |
|
Note Added: 0006021 | |
| 2005-08-10 12:16 | louisdesjardins | Note Added: 0006022 | |
| 2005-08-10 13:53 | mcornils | Note Added: 0006026 | |
| 2005-09-11 23:27 |
|
Product Version | 1.2.3cvs => 1.2.4cvs |
| 2006-01-03 20:02 |
|
Product Version | 1.2.4cvs => 1.2.5cvs |
| 2006-01-22 22:28 |
|
Status | assigned => resolved |
| 2006-01-22 22:28 |
|
Fixed in Version | => 1.2.5cvs |
| 2006-01-22 22:28 |
|
Resolution | open => fixed |
| 2006-01-22 22:28 |
|
Note Added: 0008273 | |
| 2006-01-22 22:51 | cbradney | Status | resolved => closed |
| 2006-01-22 22:51 | cbradney | Note Added: 0008277 | |
| 2006-05-15 18:11 | christoph_s | Relationship added | child of 0003821 |
