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

[pauland]

Hi Gerry,

Thanks for jumping into the defacto "symmetrical handles" thread. As a casual user I thought it might be a case of toggling the the control point to switch between symmetrical modes, so it wouldn't be a big deal for users to undo the symmetricality when necessary. For nodes in close proximity, I guess that's no real difference to what we have now, except that (as you suggest) the symmetrical mode may not be of use in such a situation.

As for the complexity of adding symmetrical handles, I think that as a user and as a software devloper I can't really see much difference between dragging on one point to move a pair of points and dragging on one point and then another to do the same thing.
As a developer (as I have already intimated I'd just be looking at introducing the movement of the second handle myself, rather than insist the user drag it independently).

I appreciate your and Johns input.

[instinctive.de]

This is way OT for the thread subject but.. ..would it really be that complicated?

For example, symmetrical beziers just require a tweak to the UI to lock/unlock the handles so they are symmetrical, then adjustment of either handle becomes a double update - with the position of the opposing handle being moved according to how the handle being edited is moved. As a long time software developer, I can't see any great complication. Just something to think about.

In general, I would have thought that the complication involved in supporting the WYSIWYG html generation would make many vector tweaks look trivial, though I completely understand the funding argument that you have put forward.

What happens if the user inserts a point on a segment adjacent to a symmetrical handle?

(Just one of a dozen examples

[instinctive.de]

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
}

There are more ways to "manipulate" handles than to drag 'em with the mouse, you know?

[instinctive.de]

Well, OK, I see another *CODER* has already made the points I've just made. Well. Anyway

[pauland]

There are more ways to "manipulate" handles than to drag 'em with the mouse, you know?

Certainly.

Dragging a point is what a user does to express their wish to update the underlying bezier curve. In an ideal world, that action would simply result in a request to update the underlying bezier model and then with the model updated, update the display to reflect the change to the bezier. This would reflect the standard Model-View-Controller design pattern and software architected like this is impervious to whether you drag a point or click a button or enter a value in a dialog box since they are UI concerns that are separate to the underlying model. The mathematics for the curve of the bezier belong to the model not the UI and have nothing to do with whether a single bezier handle is manipulated independently or as part of a synchronised pair.

In the MVC design pattern UI changes in the View don't necessarily require substantial changes to the underlying model.

It doesn't really matter what I think - I'm not changing the code. I'm sure that the developers have sound reasons as to why such a simple thing is hard, but I won't agree that in other situations it has to be a hard thing to do and it has little to do with being able to drag a point with a mouse, change it's location with a dialog box, or nudge it with the keyboad - they all do the same thing - change the location of a point.

Paul

[pauland]

One thing I'd like to make clear - I have no issue with Xaras developers and if they say something is difficullt to do, I believe them - after all they have to do it.

My comments about the symmetrical bezier development is more about how I imagine it could be done, rather than a reflection on the reality of Xtreme's code. From an abstract development point of view, symmetrical handles shouldn't be a big deal. We all know from bitter experience that the reality of coding on an established codebase can be rather different.

I am not at war with the Xara developers, nor am I planning to upgrade XaraLX to have symmetrical bezier handling anytime soon.. ;-)

[instinctive.de]

My comments about the symmetrical bezier development is more about how I imagine it could be done, rather than a reflection on the reality of Xtreme's code.

The thing is that from my experience, the "reality of code" is very rarely as ideal as in a theoretical world, with theoretical concepts such as "MVC" and whatnot. Most code just evolves along with the needs and expectations, and at some point it simply isn't so well centralized and consistent anymore, no matter how hard you try.

That's why frequent rewrites take place - to tidy up the mess that was left over the years.

And there's another point that I *suppose* could have something to do with this. Xtreme is very fast - and fast code is rarely 'well designed'

[Soquili]

Thanks John, Paul, Gerry and Alexander for an interesting discussion.

Xtreme is very fast - and fast code is rarely 'well designed'

I remember coding contests 30 to 35 years ago where people would write fast routines in minimum lines of code. They were very fast but extremely difficult to read and decode.

Not saying this is true of the code in Xtreme, just a nostalgic memory of some fun and friendly competitions.

[instinctive.de]

I once participated in a "4k demo competition", where the requirement was to write a demo (a procedurally generated movie without any kind of images stored) that fits in 4 kilobytes of code - that's really not a lot I only made the 9th place of 13, but anyway, it was fun

In general, I tend to write 'messy' code too. It does work well, and it's not "stupid" - i.e., I do make a lot of use of code reuse etc. - but not in a "nice" way with well-thought out "interfaces" and all this stuff, much less do I write object-oriented code. But that's really off-topic now and these discussions have taken place elsewhere

Just wanted to point out that even the simplest changes in core code can cause a fantastic chain reaction of bugs elsewhere

[GerryI]

And there's another point that I *suppose* could have something to do with this. Xtreme is very fast - and fast code is rarely 'well designed'

I'd have to disagree with this. Fast code is almost always well designed, but it is specifically designed to be fast rather than to be easily maintainable...

Gerry