Howto color individual meassage arrows and combined fragments?

0 votes
asked Sep 3, 2015 in Wanted features by peter.loborg (360 points)

Persuing the possibiliy to color-code differences in a diagram I'm trying to color individual messages and group element (combined fragments). This does not seem to be supported though?

If i write

A -> B ++ #Blue : <color:Blue>theMessage(arg1, arg2, \n longArg3)

...I get a blue lifeline and the first line of the message text is blue, but not the second line with "longArg)".
Would it work to allow an altenative color format at most places where #color can be used, a format that would allow us to specify several parts?

A -> B <line:Blue fg:Black bg:PaleTurquoise> : theMessage(arg1, arg2, \n longArg3)

where 'line' would cater for any line (arrow line or border) and fg/bg handles text (foreground) and background?
If we then add the '++' notation on the same line the resulting BES on the life line should also be covered by this color specification.

If this is not wanted one can put the ++ on a separate line:

B++ <line:Blue fg:Black bg:PaleTurquoise>

or using the normal syntax

activate B <line:Blue fg:Black bg:PaleTurquoise>

Obviously the foreground spec does no good here - but it shold not be an error to allow it there.

Similar argument for group, ref, opt, alt and the like - a way to specify these three per such object.

For notes there is a workaround as we at least can control the background color as it is, but adding this possibility would add the control.

For participants we can't control the dashed deactive part of the life line, and hence that tripple would be valuable there too.


4 Answers

0 votes
answered Sep 3, 2015 by PeterBakker (280 points)
The correct working code (tested with the TEOZ engine) is something* like:

A-[#Blue]>B ++ #Blue: <color:Blue>theMessage(arg1, arg2,</color>\n<color:Blue>longArg3)</color)


(copy/paste doesn't work so I had to type the tested code over by hand)



commented Sep 3, 2015 by plantuml (247,300 points)
Note that this should also work with the regular Puma engine.
commented Sep 3, 2015 by anonymous
edited Sep 3, 2015
I don't understand the rationale behind having to restart the color declaraion after a inline newline. One could consider the message arrow and the message text to be one unit, and then I would like to override the skinparam setting for a particular message in one place using a declaration for all relevant parts.
The alternative is to arrange for a syntax where we can create tags and associate different constructs with a tag (tag a spcecific message as 'new', or a ref-box, and then in the skinparam section we could set up a special color scheme for elements tagged in this or that way.

Or if I stop beating around the bush - let PlantUML have two pre-defined tags 'new' and 'old', allow us to set skinparams for lineColor as well as lineColor<old> and lineColor<new> (for all skinparams) and then use a '-' or'+' as the first character on a line to tag that line as beeing 'old' or 'new'. That way we don't need individual coloring inside the constructs, and it would be easy to run a diff over two versions of a diagram and then select the common and 'old' part to generate one diagram and the common and 'new' parts to generate another. We would have elegant color marking on what has been removed and added. We could even have PlantUML do the filtering to avoid extra pre-processing of the source files - compute the diff, call PlantUML twice with command line args to only cater for common-and-old or common-and-new.

commented Sep 3, 2015 by PeterBakker (280 points)
I decided to make a html/javascript front-end which talks to a PlantUML server to hide some of the PlantUML complexity. I now have a script which:
- enable word-wrapping (for participants, activities and notes), no need to use \n anymore
- color an activity (text + arrow) red, even when the text is wrapped
- accepts participant names with spaces without the need to enclose the names in double quotes
- apply one standard basic sketchy style (which is done in the background)
- enables the TEOZ engine for all scripts in the background

Although I'm not a programmer I decided to try writing this to make the PlantUML files easier to make and read and to be certain that I use a basic consistent style.
0 votes
answered Sep 3, 2015 by plantuml (247,300 points)

Thanks for your suggestions!

With the last beta, we have enable:

activate Bob #blue #red

where the second color is the border one

About the text color, you have indeed to repeat the color setting:

A -> B : <color:Blue>theMessage(arg1, arg2, \n<color:Blue> longArg3)

About group, there is an undocumented feature :

alice -> bob
alt #red foo
alice -> bob
end group

But you cannot (yet) change line color.

We probably have to think about a better/more consistent syntax about all thoses color settings.

commented Sep 3, 2015 by anonymous
Thanks - this might at least give me a theoretical chance at color coding diffs in sequence diagrams.
0 votes
answered Sep 4, 2015 by plantuml (247,300 points)

Today, it's possible to specify individual colors using the following examples:

A -> B #red theMessage(arg1, arg2, \n longArg3)

activate Bob #blue

class foo #red

We are thinking about generalize the syntax, introducing text/line/back keywords to be able to define several colors:
So this will be possible:

A -> B #text:Blue#line:FF0000#back:red theMessage(arg1, arg2, \n longArg3)

activate Bob #back:blue#line:red

class foo #text:red#line:00FF00#back:yellow

Any though about this ?

commented Sep 4, 2015 by PeterBakker (280 points)
Looks fine to me :-)
commented Sep 4, 2015 by TJP (400 points)
Isn't it possible to declare the colors of the fragments by initialization?

Something like:
participant Bob {

And some Event-Stuf:
onActivation:Bob {

Would that be possible/usable?

Best regards,
commented Sep 6, 2015 by plantuml (247,300 points)
Yes, good idea : we will implement something like that.
Thanks for the suggestion!
+2 votes
answered Sep 6, 2015 by plantuml (247,300 points)

We have started to implement something as a test in the last beta :

This is for now only working for class diagram. The syntax is not final : the idea is to let people play with it some times, to get feedback and suggestions.

The idea is to extend the existing #color syntax. Here is a working example, I hope that it's clear enough:

class bar #line:green;back:lightblue
class bar2 #lightblue;line:green

class Foo1 #back:red;line:00FFFF
class FooDashed #line.dashed:blue
class FooDotted #line.dotted:blue
class FooBold #line.bold
class Demo1 #back:lightgreen|yellow;header:blue/red



We have to add "text:" setting to be able to change text color.

Any though ?

commented Sep 7, 2015 by peter.loborg (360 points)
Yes - very usefull extension to the base syntax for providing color info that can be reused in various (all?) places. It would be really good if the text: variant cover (provides a default for) all lines of text within the colored construct.

I would prefer prio on these suggestions as follows:
- (high prio) single color syntax for line|background/fill|text color in basic diagram types (class, sequence, activity, component)
- the line style syntax (also a useful extension - but I wold actually prefere focus on life line handling in sequence diagrams before adressing this part...)
- extend this advanced color support to remaining diagram types where applicable
- (lowest prio or skip entierly) multi color gradients - don't spend effort here, more flashy than useful.

commented Sep 9, 2015 by plantuml (247,300 points)
Ok, we will try to follow your priority, even if we are driven by another constraint: we want to ensure ascending compatibility, and we don't want to break any existing feature.
So we are adding this new syntax very slowly and carefully. We'd better be slow and conservative.

Work has been started on class/object/usecase/component diagrams.
With the new beta following examples are working:

component bar #text:yellow;line:green;back:lightblue
actor bar2 #77F;text:red;line:777
bar --> bar2 #red;text:blue : example

class cl1
class cl2
cl1 --> cl2 #red;text:blue : foo3

Our final goal is to implement this new color syntax *everywhere*, but right now, we are focusing only on class/object/usecase/component diagrams.
If you want to help, feedback on non-working features on thoses diagrams are welcome!

Thanks again,