View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0013676||Scribus||Properties Palette||public||2016-01-23 17:43||2016-11-15 13:14|
|Status||closed||Resolution||no change required|
|Target Version||Fixed in Version|
|Summary||0013676: move a control point outside the existing boundary of shape = changes X & width values in PP|
|Description||Copied from 0007628:0038216|
One thing I have noticed is that if you move a control point outside the existing boundary of the shape, the X/Y/Width/Height values change accordingly, which seems strange to me. For example, draw a rectangle, double-click to get the node editor, select "Move Control Points", drag a control point of the top-left corner of the rectangle to the left. You'll see the X and Width values change in the PP. Also, when you stop editing, the values in the PP reflect the maximum extents of both the nodes and control points of the shape rather than just the nodes which is what I'd expect. I wouldn't class the positions of the control points as being part of the position/size of the shape. This could be confusing. Maybe that's just me though. The canvas has its own "granularity" that can cause nodes to jump to places you might not expect them to but you've got to be zoomed in quite far and the jump is nothing like the millimetre suggested, and it only affects the node you've dragged and not the whole line/bezier. It might be helpful to know the exact value that the line has moved and what units the user is using at the time but I guess if it's happening "randomly" it might not be easy to get this info.
|Steps To Reproduce||1) draw a rectangle|
2) double-click to get the node editor
3) select "Move Control Points"
4) drag a control point of the top-left corner of the rectangle to the left. Result: You'll see the X and Width values change in the PP.
||The position/size of an arbitrary shape is basically determined by its bounding box. So when moving a control point outside the shape boundary, depending how the shape change, there is plenty of chance that the position/size of the shape will change. So this is totally expected. And this is why there is no way control points can be excluded from the computation of position and size.|
That doesn't sound right to me. The position/size of an object should reflect what the user can see, not what the internal representation of it is.
Having things as they are means that - for example - the alignment functions look like they don't work when control points are outside the visible shape. This makes it look like Scribus doesn't work properly. The user doesn't care how the shape is constructed, only what it look like on the screen/page.
It's the visible thing that the user uses to make their layout so that's what should be reflected in what happens when they manipulate things. You make a layout according to what you can see rather than what lurks underneath.
What currently happens is not "expected behaviour" to the average user. For example, when you ask someone where the left-hand extent of a shape is they will point you to the left-hand-most bit of the shape they can see. They will neither know or care where the control points are; they're only interested in what they can actually see.
A quick test with Inkscape shows that it works the way I - and the average user - would expect and not the way that Scribus works.
>> A quick test with Inkscape shows that it works the way I - and the average user - would expect and not the way that Scribus works.
I just did a quick test in inkscape and Inskcape clearly shows inaccurate informations about the shape position while editing notes:
- create a shape and verify shape position while using selection tool
- modifying control nodes in a way that shape bounding box position changes
- escape edit mode and click selection tool again
- the shape position has changed!!!
Modifying control points affects the global shapes aspect. So it is simply impossible that shape position never change when modifying control nodes.
|2016-01-23 17:43||Kunda||New Issue|
|2016-01-23 17:44||Kunda||Description Updated||View Revisions|
|2016-01-23 17:44||Kunda||Reporter||Kunda => GarryP|
|2016-01-23 17:45||Kunda||Relationship added||related to 0007628|
|2016-01-23 17:46||Kunda||Tag Attached: #please_test|
|2016-01-23 17:53||Kunda||Target Version||=> 1.5.3|
|2016-01-23 19:36||Kunda||Relationship added||related to 0012177|
|2016-01-23 19:37||Kunda||Relationship added||related to 0012118|
|2016-01-23 20:14||jghali||Note Added: 0038375|
|2016-02-10 13:11||GarryP||Note Added: 0038616|
|2016-02-12 22:15||Kunda||Note Added: 0038684|
|2016-11-15 13:13||jghali||Note Added: 0042417|
|2016-11-15 13:13||jghali||Note Edited: 0042417||View Revisions|
|2016-11-15 13:13||jghali||Target Version||1.5.3 =>|
|2016-11-15 13:14||jghali||Assigned To||=> jghali|
|2016-11-15 13:14||jghali||Status||new => resolved|
|2016-11-15 13:14||jghali||Resolution||open => no change required|
|2016-11-15 13:14||jghali||Status||resolved => closed|
|2016-11-15 13:14||jghali||Resolution||no change required => fixed|
|2016-11-15 13:14||jghali||Resolution||fixed => no change required|
|2016-11-15 13:14||jghali||Note Edited: 0042417||View Revisions|