Extending standard appearance

[Thomas Mercer-Hursh]

I just ran into a lovely example of why all standard element and component appearances should be defined by shapescripts which are published and can thus be overridden..  Take an element, say Component, define a stereotype for it and apply it to some element one has created.  Customize the shape script for that stereotype to get an appearance that works ... which may be a little hard now because of the quirks, but let's say that one is happy.  Then suppose one runs into a diagram where one wants the tags to display, so one goes to the diagram properties and clicks that box ... but nothing happens.  Well, it doesn't happen, of course, because one has overridden the appearance and didn't include a section for tags.

Now, I haven't tried it yet, but I'll bet that if I define a stereotype appearance that has a section to show tags, that it won't pay attention to the diagram properties switch.  I.e., they will either always be there or always not.

This can't be hard to fix.

[«Midnight»]

[smiley=thumbdown.gif]

Right on Thomas!

Both these issues - the greater question of making shape scripts applicable to all element drawing, and the specific issue of handling compartments (for tags or otherwise) with shape scripts - have been brought up.

In the specific case the last I heard from Sparx, here in the forum, was that compartments are not handled. There are some very limited workarounds, but the bottom line remains that shape scripts have no means of handling, or even detecting, compartments gracefully.

The general issue has not been addressed. Although shape scripts have evolved slowly, we have yet to see an version 2.0 (or even 1.x for x much more than 0). There's certainly vast leverage here, for limited work.

[You're welcome to read through my litany of posts on the subject, and there are others (litanies) out there too. Doing so will not make you happy.]

There is even an event that can be trapped through automation as each compartment is about to be drawn. Of course, this will not work (effectively) with scripts.
[smiley=thumbdown.gif]

David

[Frank Horn]

There is even an event that can be trapped through automation as each compartment is about to be drawn

Then why not introduce more events like OnDrawingShape(ElementID, Graphics) and drawing methods on a Graphics class passed there, so that everything can be overridden as required, and forget about shape scripting?

Only dreaming...

[«Midnight»]

Actually, I think we'll need both the internal rendering engine and shape scripts for some time.

In order to make the scrips work well, we'd need some means of dividing up the work of a script. Different sections of the script would be responsible for things like the main shape outline, decorations, compartments, and text rendering.

With that change in place there could be event support. Perhaps even the same events as those used for handling the (extended) internal rendering engine.

But that's still a dream...

[Thomas Mercer-Hursh]

Point being, though, that it is a very small dream in terms of the difficulty of realization.  One has the ability now to draw different components and fill them with various contents.  One has if statements for deciding which appearance to use or which contents to display. One has access to tags and such.

What we are missing, really, is a measure of precision and control along with access to a little more information.  Somewhere in there is a rendering engine which is doing a better job than the one being used for shape scripts ... at least it sure seems like there must be two since the shape script one seems so crude.  So,

1. Unify the engines, if that needs doing, or provide shape scripts with access to the same API that is being used for built-in renderings.  This would include improved precision, I think.

2. Add some font controls.

3. Add some basic string processing ... that has *got* to be off the shelf.

4. Add a bit more information about the environment, e.g., which switches are set for the diagram.

5. Allow us to control the *whole* connector, not just the line.

6. Add a handful of additional properties, such as separate vertical and horizontal scalability.

Off the top, it sounds like a couple of weekends work and it would sure make some of us happier!

[«Midnight»]

Agreed throughout.

Most strongly agree - and I've said it above and many other places - that the payback here would be huge compared to the front end work. [And yes, I agree that the front end necessary to achieve first benefits would be small. Sparx has already done the hard part, which was making scripts work at all.]

[Eve]

For what it's worth, I agree with nearly all of what's being said here.  It's just not a priority at the moment.  But feel free to send in feature requests, and encourage everyone who cares about this at all to do the same.

5. Allow us to control the *whole* connector, not just the line.

How much does this thread help?  You can also control connector labels with shape leftbottomLabel etc.

[Thomas Mercer-Hursh]

The "label" is not the issue.  The issue is the arrowheads or whatever is the overall appearance,

To me, if I am applying a distinctive appearance, the whole issue is that the appearance is taking the place of stereotype labels and such.  The point is that i am trying to convey a relationship by appearance.

[Eve]

So ignore my comment about labels if that's not pertinent to your situation.  The link that I posted is to a shape script for a connector drawn as a dotted line with a generalization shape at one end, and a composite (filled) diamond at the other.

Then, if you like the connector except that you have to apply a stereotype to get it, and you don't want the stereotype label shown.  Create an empty shape middlebottomlabel.

[«Midnight»]

...It's just not a priority at the moment...

There's the gist of what I've been getting.

Obviously something is (or some things are) the priority(ies) at the moment, for quite a few moments so far.

So the big problem seems to what we're getting across. Sparx is very aware of the pros and cons of the situation, at least as far as return for work invested. What needs to be communicated is the business case for addressing this before moving forward on the current perceived priorities.

Of course this assumes that we can figure out what the current priorities are, that a business case exists, and that we can convince Sparx.

Ideas anyone? [Interest anyone?]

[Thomas Mercer-Hursh]

This seems like a classic problem of low hanging fruit which never gets picked because all attention is focused on high profile items.  I've seen many a software company that will list out all the candidate areas of work for the next release, prioritize them, and then select some set from the top of the priority list and that becomes the target for the next release.  Sounds sensible, except that there are things which never seem to make it into the top priority, but which nevertheless matter to at least some people, and which take a very small amount of effort to implement.  My recommendation to any software company is that they dedicate some percentage of the development effort for a new release, even if it is only 10% or 15%, and apply that to a list of small items which would otherwise never make it into the priority list.  This might knock one bigger item off the list, but it will get half a dozen little ones done.

[«Midnight»]

Which is just where I'm going on this.

That still leaves the matter of how to convince Sparx of this. I'm out of suggestions (pun intended). It's possible that a flood of feature requests would help, but I don't think there's enough 'flash' in this one for it to generate that kind of groundswell of support.

Sigh...

[Paolo F Cantoni]

I've ony just got to this...

This whole thread is worth a bump...

Any progress actually been made?  Was it actually worth putting in the additional feature requests...

Paolo