Thank you and good bye! I'm no longer Xara's target audience.

[pauland]

I'm not sure what you are trying to insinuate, but I suppose you are not suggesting to rewrite Xara in Java or actionscript, don't you?

LOL, no insinuation, just some sympathy for using C++ perhaps, though still surprise that the symmetrical bezier should change anything but a limited section of code. I think we're way off topic now and boring people silly.

[steve.ledger]

Actually, this thread is getting interesting now

[covoxer]

...still surprise that the symmetrical bezier should change anything but a limited section of code.

The problem is in insuring stability. The essential change is not that big or complicated, the process of making sure that the rest of the code will remain reliable may require a lot of work and more code changes and testing e.t.c. As I say. The more basic feature we change the higher is the risk of having unpredictable consequences. For example, any changes in the HTML export filter are virtually safe so are much more trivial to implement safely.

I think we're way off topic now and boring people silly.

All this thread except for a handful of posts is off topic so why should we care?

[planetsquid]

Actually, this thread is getting interesting now

Agreed. For us geeks who find enjoy programming - this is fascinating.

I would quite happily watch a fly-on-the wall documentary about the development of Xara products...

Rich

[pauland]

I haven't looked at the Xara source code, but in an ideal world the manipulation of a bezier curve might have an interface like this:

onDrag(bezierHandle)
{
var thisControlPoint:BezierControlPoint = bezierHandle.getControlPoint();
var handles:Array of BezierHandle = thisControlPoint.getHandles();
for each (handle in handles) // there will only be two handles
{
if (handle == this)
{
handle.x = this.x;
handle.y = this.y;
}
else if ( symmetricalMode )
{
newHandle = bezierControlPoint.getSymmetricalHandle(this); // calculates opposing position of symmetrical handle
handle.x = newHandle.x;
handle.y = newHandle.y;
}
thisControlPoint.updateParentBezier(); // updates curve to fit control point manipulation
}

So that's how I see the symmetrical operation working, as a pseudocode - i agree you need some more UI interaction to switch in and out of symmetrical mode, but the effect on other code should be minimal.

It's not a criticism - Xara is written as it is written but ideally this kind of change should not be a big thing. I agree that there may be a lot of regression tests afterwards, but typically this would be on a collection of changes, not just this one. Naturally you may be unit testing changes, but the actuall symmetry change should only be a tiny section of code.

John, I want to make it clear I'm not criticising you or any other developer because you have to work with the real code and actual situation, we're just having a bit of a discussion about a particular feature.

Paul

[covoxer]

Now why have you written this pseudocode thing? Do you think that other programmers don't know how to do this? Or Xara programmers are special?

Or, perhaps you just want to create illusion of simplicity (not much text there) in other readers who are not programmers?

[pauland]

I'm just trying to understand the complexity of the change, that's all. My pseudo code is very close to what the actionscript might be.

Might be a good time to stop.

[JokeArtist]

Yeah I think it's unfair to tell the Xara Developers how to do their job. They probably know that already but they just have to do what they're told as well. Which means following what direction the bods at the top want them to do, like anyone else in a job.

[pauland]

Yeah I think it's unfair to tell the Xara Developers how to do their job.

I certainly wasn't doing that.

[GerryI]

The complexity isn't in the code that calculates the position of the opposite control point. Those calculations are actually simpler than the ones we currently do to keep the point a curve. The complexity comes with all the other operations that modify paths having to change the types of other points in the document.

The attached file (example.xar) contains a simple path where the control points (A and B) on the middle path point (P) approximately line up with the rectangle (select the middle point and see). Imagine that this middle point is set to be symmetrical and now add a new point to the middle of the left bezier segment by clicking on the curve. This operation has to change control point A to keep the shape of the path the same and this causes the point P to no longer be symmetrical (incidentally, this is why having symmetrical points is not actually as useful as people might think, they only give a more smooth curve where the segments on each side of the point are similar in length). If the point was set to be symmetrical then grabbing either control point A or B would cause the other point to move and change the shape of the path in a way the user would not expect. E.g. move B slightly to the right and A would move to the left of where it originally was making the left side of the line look different. In the extreme case where the new point you added is quite close to P, the resuting path is totally useless (afteredits.xar). The logical solution is to clear the symmetrical state of point P when the new point is added. Similar problems occur with various operations that edit paths and even if the "fix" can be done in a general way that affects all operations with minimal code changes, they all need to be carefully tested.

There are already some instances in Xtreme where the cusp/curve state gets confused causing this sort of unwanted behaviour (e.g. you drag a control point on what appears to be a cusp point and it suddenly changes back to being curved) and ideally we want to fix those rather than adding any more...

Gerry