Howto color individual meassage arrows and combined fragments?

Question

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.

Br/Peter

Answer 1

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)

 

Regards,

Peter

Comments

Thanks,
Note that this should also work with the regular Puma engine.

---

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.

//Peter

---

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.

Answer 2

Thanks for your suggestions!

With the last beta, https://dl.dropboxusercontent.com/u/13064071/plantuml.jar 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.

Comments

Thanks - this might at least give me a theoretical chance at color coding diffs in sequence diagrams.
Br/Peter

Answer 3

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 ?
Thanks!

Comments

Looks fine to me :-)

---

Isn't it possible to declare the colors of the fragments by initialization?

Something like:
participant Bob {
#text:blue;
#back:black;
#line:yellow;
}

And some Event-Stuf:
onActivation:Bob {
#line:red;
#lifeline:blue;
}

Would that be possible/usable?

Best regards,
Timo

---

Yes, good idea : we will implement something like that.
Thanks for the suggestion!

Answer 4

We have started to implement something as a test in the last beta : https://dl.dropboxusercontent.com/u/13064071/plantuml.jar

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:

@startuml
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
 

@enduml

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

Any though ?

Comments

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.

Br/Peter

---

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 https://dl.dropboxusercontent.com/u/13064071/plantuml.jar following examples are working:

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

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

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,