Arc Shapescripts - Rendering Order

[Paolo F Cantoni]

After using this product for over a decade, I've just noticed that shapescripts for arcs draw the elements ina (to me) non-intuitive way.  It appears EA will draw shapes source and target (not clear which order) and THEN shape main.

This makes it REALLY difficult to suppress the main line at either end so that it is not visible if you wish to creatre an end shape that doesn't include the line.  For example, draw a circle as either source or target and you'll see what I mean. 

Because of the order of rendering, even a fill command won't do it.

It seems to me that if the order were shape main THEN shapes source and target, we'd end up with a more flexible shape script mechanism.

I think this could be done without affecting any existing shapescripts.

What do others think?

Paolo

[Glassboy]

Imagine what you could achieve if Shapescript was replaced with SVG   

[Paolo F Cantoni]

Imagine what you could achieve if Shapescript was replaced with SVG   

Man, you doin' craaaazy talk!   

Paolo

[qwerty]

Imagine what you could achieve if Shapescript was replaced with SVG   

You would loose the ability to program conditions.

q.

[Glassboy]

Crazy sweet HTML output tho.

[Eve]

Imagine what you could achieve if Shapescript was replaced with SVG   

To expand on what qwerty already said, shape scripts are not just about defining an image to render.

Shape scripts are for defining a mapping between the EA object model and the EA rendering engine. They are limited in the access they provide to the metamodel, the language syntax, the rendering engine and in this case when they are called.

If you want to see how useful SVG would be, use alternate images on your elements. You won't be able to do that for connectors, but I'm sure you can work out why not and why SVG won't work there either.

[Paolo F Cantoni]

Imagine what you could achieve if Shapescript was replaced with SVG   

To expand on what qwerty already said, shape scripts are not just about defining an image to render.

Shape scripts are for defining a mapping between the EA object model and the EA rendering engine. They are limited in the access they provide to the metamodel, the language syntax, the rendering engine and in this case when they are called.

If you want to see how useful SVG would be, use alternate images on your elements. You won't be able to do that for connectors, but I'm sure you can work out why not and why SVG won't work there either.

As You would guess Simon,

I DO understand all that - but it may not be obvious to all.  MY point was that the limited access is just that; somewhat too limited.
Take my point above, the order of rendering is somewhat arbitrary and ONLY the unfortunate outcome brought it to my attention.
So, is there any point in placing a feature request/bug report to get this changed?

Paolo

[Eve]

Paolo,

I wasn't suggesting you didn't know the difference between a shape script and an SVG. I was responding to Glassboy.

As I can't demonstrate that there aren't users who want the current behavior, you chance of a change here is slim.

Does something like the following work for you?

Code: [Select]

shape source
{
    noShadow=true;
endpointx = 20;
endpointy = 0;
scalable = false;
rotatable = false;
   
    ellipse(0,-10,20,10);
}

[Paolo F Cantoni]

Paolo,

I wasn't suggesting you didn't know the difference between a shape script and an SVG. I was responding to Glassboy.

Understood.

As I can't demonstrate that there aren't users who want the current behavior, you chance of a change here is slim.

From first principles, I might argue it's isn't possible that ANYONE would want the current behaviour - given its consequences.  Can you (or anybody else) come up with a rationale for it?

Does something like the following work for you?

Code: [Select]

shape source
{
    noShadow=true;
endpointx = 20;
endpointy = 0;
scalable = false;
rotatable = false;
   
    ellipse(0,-10,20,10);
}

No, because the target shape "mysteriously" disappears when you set the source shape to that code.   

I tried duplicating the code in the target and it then appears, but if I change the shape from a circle which is rotationally identical to a shape that isn't (such as a closed arrow) the the rotatable = false; "kicks in" and it looks completely wrong.  OK, so just remove the rotatable = false;...   But if you do that, the shape disappears again! 

Can YOU guys get it to work?

Paolo

[Eve]

You can argue from first principles that it's impossible for anyone to implement something like the UML nesting notation and omit a line from the script either because it was unnecessary or because two anti-aliased lines on top of each other increase the perceived width? That's just one example of a real world notation that would be broken by making the change you're proposing.

Yes, the end point can only be used on a non-rotateable end, and I think both ends need to use that style. I don't think there has been a need for anything else in the past.

The use of shape scripts like that has been working since the Information Engineering notation was added to EA.

Maybe I wasn't clear. Can you make it work for you, even if it's not ideal?

[Paolo F Cantoni]

You can argue from first principles that it's impossible for anyone to implement something like the UML nesting notation and omit a line from the script either because it was unnecessary or because two anti-aliased lines on top of each other increase the perceived width? That's just one example of a real world notation that would be broken by making the change you're proposing.

Not sure I follow why it would break, but let's leave it there.  I accept it isn't going to happen.

Yes, the end point can only be used on a non-rotatable end, and I think both ends need to use that style. I don't think there has been a need for anything else in the past.

Just a point of clarification here.  Are you saying: "If one side has a non-rotatable end, then the other side must have a non-rotatable end" - by definition, by the current design or by your belief (no offence intended - use of "I think" for "I believe").

The use of shape scripts like that has been working since the Information Engineering notation was added to EA.

I wondered how you got that to work.  So now we know...

Maybe I wasn't clear. Can you make it work for you, even if it's not ideal?

If that's all that's available; then, I guess, there's not much option. 

Paolo

[Eve]

Just a point of clarification here.  Are you saying: "If one side has a non-rotatable end, then the other side must have a non-rotatable end" - by definition, by the current design or by your belief (no offence intended - use of "I think" for "I believe").

Think in this context means my observation prompted a very old memory of the design.

[Paolo F Cantoni]

Just a point of clarification here.  Are you saying: "If one side has a non-rotatable end, then the other side must have a non-rotatable end" - by definition, by the current design or by your belief (no offence intended - use of "I think" for "I believe").

Think in this context means my observation prompted a very old memory of the design.

Thanks, Simon,
That's what I thought, but didn't want to make any assumptions.

As per my previous question, is there any point in adding a feature request to make the rotatable optional at either end?  From what I can see of the observed behaviour with my small amount of testing, I wouldn't have expected there'd be a problem.  The original design was created for a specific use - for which I can see the rationale, but I would consider the mandatory requirement for Rotatable=false to be an unintended consequence of the design.

Paolo

[Eve]

I can't see any negative consequences for allowing an end point to be specified for rotatable ends or for allowing a single rotatable end.

[Paolo F Cantoni]

I can't see any negative consequences for allowing an end point to be specified for rotatable ends or for allowing a single rotatable end.

Thanks,  reported...

Paolo