PlantUml define relative position of components - plantuml

I'm actually trying to generate a component diagram with PlantUml. Is it possible to define the relative position of the different components? What I want to define is: ComponentB is left from ComponentA. ComponentC is below ComponentA, ...

A typical approach is to mark a line as hidden.
One thing to keep in mind is that hidden is only supported for left-to-right ->, and top-to-bottom --> lines, so you need to place the left and right side accordingly (syntax X <[hidden]- Y doesn't seem to be supported).
#startuml
class ComponentA
ComponentB -[hidden]> ComponentA
ComponentA -[hidden]-> ComponentC
#enduml
See also How to correct PlantUML Line Path for more positioning tips.

You can follow guidelines from here:
Layout of grouping component
In general when you write connections like -> you just have to know that there is special notation for right arrow, left arrow, bottom arrow, top arrow:
This has special meaning for plantUml:
-l->
-r->
-u->
-d->
It means to place arrow on the left or right or up or down if possible.
Lets imagine this diagram:
#startuml
node "My system" {
[A] -> [B]
[C] -> [B]
}
#enduml
This looks horrible, you can fix this by directing PlanUml with arrow directions.
#startuml
node "My system" {
[A] -d-> [B]
[C] -r-> [B]
}
#enduml
Will generate this:

Related

How to get a non-linear layout in class diagram?

A class diagram seems to always be linear - either in horizontal or, if I add left to right direction, vertical.
However, in many cases the layout could do a better use of the screen space. Check this one out:
This last diagram could easily have A as a center in the middle of the screen and then have all other classes around it.
I know that PlantUML uses Graphviz behind the curtains to do the layout, which supports a variety of styles. So, can I tell PlantUML to do something smarter when it comes to class diagrams?
Do you mean something like
produced by
B -l-* A
C -l-* A
A *-r- D
A *-r- E
I defined the classes in ascending order A, B, ..E. Check out the Layout Section of the new Hitchhiker's Guide for details. Or the Section Changing arrows direction in the class diagram page of plantuml.com.
(Tested in Linux Mint 20 Ulyana, Emacs 26.3, org mode 9.3.1, PlantUml 1.2018.13 src block, graphviz 2.43.0)
Looking at the code of your second example, we see it has horizontal associations, e.g., A *- B. If you always use vertical associations, e.g. A *-- B, GraphViz does always does a better job:
A *-- B
A *-- C
A *-- D
A *-- E
A *-- F
A *-- G
A *-- H
A *-- I
A *-- J

How do I avoid labels overflowing container boundaries with PlantUML?

I'm trying to find a way to make sure labels of items in a container do not overflow or overlap container boundaries. So far I could not find any setting that would help.
This content:
#startuml
left to right direction
node "inner" {
()XyzAdapter
}
node "inner-impl" {
[XTXAdapter] - XyzAdapter
}
node "Other Groups" {
FTP - [Second Component]
[First Component] --> FTP
}
#enduml
Creates the following rendering in every online/offline PlantUML setup I could get my hands on:
As you can see, both FTP and XyzAdapter are rendered without any concern for their container boundaries.
It is even worse from within Vs. Code using the PlantUML plugin because it also decreases the space between containers.
Are there any parameters or tricks I can use to avoid this? You can use both liveuml and planttext to observe this behaviour.
If you do not insist on keeping the exact same layout, you could add another dash ("-") where you have only used one in order to have two dashes for all your edges. That renders a diagram like the one below with all labels being legible.
#startuml
left to right direction
node "inner" {
()XyzAdapter
}
node "inner-impl" {
[XTXAdapter] -- XyzAdapter
}
node "Other Groups" {
FTP -- [Second Component]
[First Component] --> FTP
}
#enduml

How can I "touch" one component from another without nesting?

Given this component tree:
c0 - c11 - c12 - c13
\
c21 - c22
What is the best way to send some data from c13 to c22 ?
In my case I had something like forum page(c0): there were message feed (c11), message (c12), "quote" button (c13) and block with some controls (c21) including message form (c22).
What I wanted is to add some text to message form on quotation click.
So I added callback (via prop) onQuote to message that is just being called with message text (with some transformations) like this: this.props.onQuote(txt). Then I provided it from root component (c0) via passing it in a chain: c0 - c11 - c12. And since text in message form is kept in c22 state I had to create method like .setText(txt) and create delegation from c21 to call it from c0.
This looks pretty bad (another word, actually) and complicated (too much code) to me.
How would I do better? I don't wanna use global state and I don't believe that this is the react way to do things. I don't really like the whole "passing" thing when there're many components in the middle that do nothing with data but just pass it.
The preferred and proposed method by Facebook itself is to lift up state to at least to the nearest common ancestor of both components.

maya makePaintable attribute

stupid question but I m having an issue with that.
Can you make more than 1 attribute paintable on the same shape ?
I am adding 3 double array attributes for testing purpose and I make them paintable trough a loop while adding them.
When I do that, I can t paint them through my test and to verify that i tried painting it via right click on the mesh -> paint -> mesh and I only see the usual paintable attributes + the first one I defined...
Is there anything specific to do to declare more than 1 attributes paintable ?
Thanks !
I found out why it wasn't working. The documentation for makePaintable is wrong ...
cmds.makePaintable('node','attribute') like shown in the documentation doesn't work. Instead, you have to do cmds.makePaintable('nodeType','attribute') and your mesh has to be selected (I suppose as you don't specify it in the command)
It is now working.

Is it possible to join a body from two sides to different static bodies

b2Body* foundation =[self createStaticBodyAtLocation:CGPointMake(15, 15) withSize:CGSizeMake(35, 35)];
b2Body* beam=[self createDynamicBodyAtLocation:CGPointMake(105, 35) withSize:CGSizeMake(150, 10)];
b2RevoluteJointDef revoluteJointDef;
revoluteJointDef.Initialize(foundation, beam, b2Vec2(30.0/PTM_RATIO,30.0/PTM_RATIO));
_world->CreateJoint(&revoluteJointDef);
The above code creates a static and a dynamic body and then joins them with a revolutejoint. Here's what I get:
Then I add the following lines to add another body, which is a static circle and then join the circle and the previously added bar on the other end of the bar.
b2Body *jointBall=[self createCircleAtLocation:CGPointMake(160, 135)];
revoluteJointDef.Initialize(jointBall, beam, b2Vec2(100.0/PTM_RATIO,10.0/PTM_RATIO));
_world->CreateJoint(&revoluteJointDef);
But here's what I get:
After adding the circle, I can't move the bar. It's fixed. But I'd expect it to join to the circle. I've tried to change the anchor point to different positions but it doesn't help. What am I missing? Maybe it is not possible to join a dynamic body to more than one static bodies.
From the box2d manual:
All joints are connected between two different bodies. One body may be static.
You may manually move static bodies, but you should be careful so that you don't squash dynamic bodies between two or more static bodies
What you've effectively done here is squash the bar body between two static bodies with revolute joints. Static bodies cannot move at all, so the output you're seeing actually makes sense. The first revolute joint (connecting box and bar) allows the far end of the bar to move (rotationally). However, when this far end is connected to another static body by another joint that restricts all motion but rotation, it cannot move anymore. Thus, it makes sense that the rotation of your bar body will become fixed after joining it with two different static bodies.
I searched through the box2d code and didn't find anything that directly sets the rotation of a body connected via a joint.
What are you trying to do? It seems like you might be trying to have the ball move along with the end of the bar, in which case I would recommend making the ball a dynamic body (so it can move). Also, depending on what you're doing, a weld joint might be more appropriate.

Resources