ShapeScripts: Additional Color Queries

[Paolo F Cantoni]

It turns out that one can combine shape scripts and default color overrides in the Settings|UML..|Stereotypes dialog.  This is, in my view, a very useful capability.  The problem is that while you can get at the User settings for the various colour queries (such as getUserFillColor()) you can't get at the settings in the Default Colors section of the dialog.  Default here means Stereotype Default.

Now, by the way, the "User" settings appears to mean the current setting in the specific diagram.  This is arrived at by algorithm.  You can set the Default Appearance of the Element (set by Element|Appearance>Default Appearance... [Ctrl+Shift+E] AND by <Element Context Menu>|Appearance>Default Appearance... [F4] - why two different keyboard shortcuts to the same dialog?).  

You can also set the Element Appearance for a specific diagram using the Format Tool toolbar.  So we have two sets of Defaults:  Those for the stereotype and those for the specific element itself.  Finally, one can set the Appearance of the Element by means of direct methods in the ShapeScript: setFillColor() etc.

The order of applicability (for a stereotyped element) is interesting.  In increasing order of override:  Stereotype Default, Element Default Appearance, ShapeScript method, Format Tool

I propose adding getStereotypeXxxx queries to allow us to get the current setting for the stereotype.  For each User method, there would be a corresponding Stereotype method:
getStereotypeFillColor()
getStereotypeBorderColor()
getStereotypeFontColor()
getStereotypePenSize()
NOTE: you can't currently set the Stereotype Pen size, but it would be very cool if you could.  Obviously, of Sparx decide NOT to implement the Stereotype Pens Size then you wouldn't need getStereotypePenSize().

I also propose adding getDefaultxxxx queries to allow us to get the Default settings for the Element.  For each User method, there would be a corresponding Default method:
getDefaultFillColor()
getDefaultBorderColor()
getDefaultFontColor()
getDefaultPenSize()

Thoughts?  Votes (in:Poll: ShapeScripts: Additional Color Queries)?

Submitted...
Paolo

[Eve]

We are in the process of evaluating a number of feature requests, and this came up.

Okay, so you currently can't get at this information from a shape script.  But I can't think of a single valid use case for why you would want to.  The only situations I can think of for using it are for specifying that the stereotype colours can not be overridden.  Doing this would destroy the consistent behaviour of element colouring in EA though.  (Yes, you can do that anyway by ignoring all colours set, but having these functions encourages it.)  So I don't want to see it happen.

So, what is a use case that you need these functions for?

[Paolo F Cantoni]

So that in my shape script I can better control what the user sees...  Isn't that the point of the shapescript?

The shapescript can react to circumstances (albeit still rather rudimentary) in ways that other rendering technologies within EA CAN'T...  For some circumstances, I want to be able to modify ONLY part of the result - I may wish to "pass through" existing externally defined rendering attributes (such as Fill colour), but modify others.

My overriding point is to provide the user with the MAXIMUM access to the upstream settings so they can make better outcomes downstream.

There's the consistency issue of EA gives us access to part of the rendering chain, but not the others...

Does that explain the rationale for the request better?

Others may have additional viewpoints.

Paolo

[Eve]

If a built-in element to EA didn't respond to the options for default fill colour or local fill colour it would be reported as a bug.  I don't see why EA should provide the tools to a shapescript to make the same mistake.

EA is providing access to the colours that are required to draw the element according to how the user has specified.  What I'm asking for, is what is a good reason a shape script should want to use the stereotype (or default) fill colour instead of the colour the user has specified.

To be clear: I don't want an answer that says "because this would be good".  I need an answer that says "this is what I am trying to do, and I'm doing it to meet this need"

[Paolo F Cantoni]

The problem is more complicated than just this specific request and compounded by the current inconsistencies in rendering within EA.

In the enterprise space, I may need to render an element differently in one type of diagram than another.  However as a supplier of shapescripts I may not want to define some rendering attributes but leave it up the the installation (not necessarily the individual user) to specify some standards.  If I can get access to the upstream definitions then I can "assist" the actual user in retaining those aspects of the rendering that are mandated by the installation.  So for example in diagrams of type XXX: whatever the Element default for this type of element, the stereotype default will be used.

I'm designing and building metatypes with rendering for world-wide distribution.  Since I can't, given the current EA technology, allow my users to customize the rendering attributes, for example: we love our Interfaces to be Yellow... I am looking for the next best thing...

Another use case is the creation of widgets to attached to shapes where the user MAY have overridden the defaults, but according to the installation rules, a widget giving the original (default) rendering might be mandated  (as a parenthetical element).

Is that enough?

Again, I ask why ONLY give us access to one set of overrides?

I'd like not to have to use shape scripts - I'd prefer, for example, that an MDG stereotype appear in the list of stereotypes justs like any other and allow the installation/user to define some of the rendering attributes to their liking - but as I've explained in the Consistent Diagram Item rendering proposal  this isn't possible as this time.

When you create a shapescript in an MDG technology (and this appears to be the only way to impose a rendering on a stereotyped item that behaves analogously to the stereotype Default attributes for a non-MDG technology) you impose a lot of constraints on the end-user.  I want to remove these constraints as much as I can.

Consequently, I'd commend re-examining the topic I mentioned above to provide a holistic solution to the problem.

Paolo

[beginner]

...To be clear: I don't want an answer that says "because this would be good".  I need an answer that says "this is what I am trying to do, and I'm doing it to meet this need"

In which case it will be enqueued in the OINO¹ of user requests.

I have the same problem as Paolo but not the time to argue any more. Times of fast developer response from Sparx are over. They are stuck with bug fixing. At least they should be. Probably they add new nifty features which introduce a couple of new bugs.

b.a.h.
¹Like FIFO and LIFO: Once In Never Out