View Issue Details

IDProjectCategoryView StatusLast Update
0001659ScribusDocumentationpublic2006-01-22 22:51
Reporterlouisdesjardins Assigned Toplinnell 
PrioritynormalSeveritytextReproducibilityalways
Status closedResolutionfixed 
PlatformLinuxOSMandrakeOS Version10.1
Product Version1.2.5cvs 
Fixed in Version1.2.5cvs 
Summary0001659: Editing overlapping frames is very challenging because when selected, a frame retains its stacking order
DescriptionDepending 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 ReproduceDraw 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 InformationI think this is a real problem because it prevents free editing of the frames.
TagsNo tags attached.
Patch

Relationships

related to 0000482 closedavox Illogical behaviour when resizing/moving a frame below another. Ctrl should not be required to do the action. 
has duplicate 0001994 closed Selecting overlapping shape select always the shape on top 
child of 0003821 acknowledged Metabug: Usability 

Activities

louisdesjardins

2005-02-10 20:00

developer   ~0003684

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.

louisdesjardins

2005-04-03 12:34

developer   ~0004053

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.

plinnell

2005-04-08 07:53

viewer   ~0004166

Louis does the hints given by Craig solve the issue ?

louisdesjardins

2005-04-08 12:12

developer   ~0004184

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

plinnell

2005-04-08 12:33

viewer   ~0004185

I'm taking the bug to make sure this documented.

plinnell

2005-07-06 11:32

viewer   ~0005407

bumping to 1.2.3

mcornils

2005-07-06 14:09

reporter   ~0005414

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).

ringerc

2005-08-09 16:41

reporter   ~0005991

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.

plinnell

2005-08-10 11:25

viewer   ~0006021

mcornils - any hints what would be ideal ?

louisdesjardins

2005-08-10 12:16

developer   ~0006022

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).

mcornils

2005-08-10 13:53

reporter   ~0006026

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.

plinnell

2006-01-22 22:28

viewer   ~0008273

its now documented at least

cbradney

2006-01-22 22:51

administrator   ~0008277

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.

Issue History

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 plinnell Note Added: 0004166
2005-04-08 12:12 louisdesjardins Note Added: 0004184
2005-04-08 12:33 plinnell Note Added: 0004185
2005-04-08 12:33 plinnell Assigned To => plinnell
2005-04-08 12:33 plinnell Severity major => text
2005-04-08 12:33 plinnell Status new => assigned
2005-04-08 12:33 plinnell Category General => Documentation
2005-04-08 12:33 plinnell Product Version 1.2.1 => 1.2.2cvs
2005-05-27 07:26 plinnell Relationship added has duplicate 0001994
2005-07-06 11:32 plinnell Note Added: 0005407
2005-07-06 11:32 plinnell Product Version 1.2.2cvs => 1.2.3cvs
2005-07-06 14:09 mcornils Note Added: 0005414
2005-08-09 16:40 ringerc Relationship added related to 0000482
2005-08-09 16:41 ringerc Note Added: 0005991
2005-08-10 11:25 plinnell 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 plinnell Product Version 1.2.3cvs => 1.2.4cvs
2006-01-03 20:02 plinnell Product Version 1.2.4cvs => 1.2.5cvs
2006-01-22 22:28 plinnell Status assigned => resolved
2006-01-22 22:28 plinnell Fixed in Version => 1.2.5cvs
2006-01-22 22:28 plinnell Resolution open => fixed
2006-01-22 22:28 plinnell 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