It's possible to define a shape for a stereotype in Enterprise Architect. How is it possible to specify an exact point on that shape to link incoming/outgoing connectors?
For example, connectors can be linked to a "Gateway" only on its corners, not to any other position on the edges. How are those corners defined as the only entry/exit point?
I don't think you can. I'm not aware of any shape script properties you can set to achieve this.
The BPMN Gateway is a stereotyped UML Decision, and the connectors-at-corners-only behaviour is inherited from that (you can test this in a regular Activity diagram). I think EA handles these differently from other elements in a way which cannot be controlled from a shape script.
Of course, you can always create your own Decision stereotype and get the same result, but semantically that might not be what you're after.
Related
I need to create a right angle with a triangular support, as seen in the example below (which I created in Blender). I know how to create the right angle, but I don't really know how to create the triangular support. The only way that I was able to think of would be to create a 2D polygon that would be the outer face of the object where the support is, then extrude it to the thickness of the support, and then extrude the rest to complete the object. This, however, seems clumsy and against the idea of CQ, where the code should be (kind of) similar to how a human would describe such object.
Is it possible to create the right angle first and then add the support? How?
I have a usecase diagram with an actor and a usecase and there is an association between the two. I want to get the source and target position of the association on the diagram. I tried considering the SX,SY,EX,EY points of the connector in the PDATA5 column of the t_connector table but it doesn't make sense for most of the connectors as they are 0 in most cases.
Is there any other way to get the positions of the connectors on the diagram?
Well, it's complicated. EA renders connectors internally. In your case you have a plain rendering. So what EA does is to find the centers of the two connected elements by looking at the element positions on the diagram (via t_diagramobjects). As you might know, EA considers all elements to be rectangular. Use cases and actors the same. This is why connectors do not attach to visible borders but swivel around an invisible frame. Now the geometric centers are calculated and the attachment to those frames (which is simple geometry).
You need to look into t_diagramlinks for the connector as well, but only if you shift attachment point or introduce bends. And of course if you have special renderings (like tree style which makes completely different things you can't re-compute (simply)). The geometry will tell how shifts are made. And the path reveals the bends. Again just simple geometry if you have standard Custom Lines being set. For every other line style: you better don't ask.
From DB side:
t_diagramlinks.geometry (SX,SY)(EX,EY)=(0,0)(0,0) - probably the line from the center of the object to the center. EDGE - where the connector starts (1 top, 2 right, 3 bottom,4 left) from the source object, t_diagramlinks.path - additional break points etc.
I'm working on a widget that displays a graph of nodes and edges using a MultiChildRenderObjectWidget that accepts a list of node widgets as children. I can determine the size and position of the children during layout and thus have the graph edges align with the square intrinsic size of the nodes. However, what if the nodes are not square (if they have a border radius for example)? Then the edges do not line up with the node's border on the diagonals. Here's a picture of what I mean:
My first guess on how to do this would be to layout all children and then during painting, keep performing hit tests along the edge line until the hit test doesn't find the child. Is there a better way of doing this?
I like this question :)
As the scope of the question is broad, I will also present you with a broad answer. That means that this is not a specific implementation but rather an explanation of the concepts needed for this.
Hit testing
You presented hit testing as a way to deal with this issue. I believe that this is not feasible in most cases, let me explain.
Iteration problem: "keep performing hit tests along the edge line" - maybe there is a good algorithm for doing this in a somewhat efficient fashion, however, if you think about it, you would have to perform a lot of checks to get results depending on the approach you take (the difficult question here is how you determine success for your algorithm, i.e. when it should stop searching).
Also note that "Hit testing requires layout to be up-to-date but does not require painting to be up-to-date.", which means that it is not intended to rely on painting in hitTest - I am also not aware of a way to perform hit tests on a canvas, so the idea of easily checking where the canvas painted might not actually be possible.
Parent data
The way I would approach this problem is using parent data, specifically BoxParentData.
Ideally, you would paint your nodes using render objects as well because that allows you to work with the parent data easily.
Before I go into a little bit of how it can be implemented, here is my idea:
You have a render object container (your MultiChildRenderObjectWidget) that can handle your nodes.
The nodes will have GraphContainerNodeParentData (example name).
Each node paints based on a description of the shape. This description could be a Path (you could use PathMetrics to evaluate that later) or something simpler if you can find a way to simplify e.g. the description of the rounded rectangle.
The node sets that shape description as its parent data (variables in the GraphContainerNodeParentData.
The render object container will be able to read the GraphContainerNodeParentData, which contains the information about the shape. Now, you will be able to go through your children during painting and read the parent data, where the shape description is stored → problem solved :)
Implementation
This is the way Stack et al. work. You can find the implementation of rendering for Stack in the framework:
Parent data implementation
Container render box implementation (btw, "container" in my answer refers to the concept of a render box that is a container for other render boxes; it has nothing to do with the Container widget :D)
Furthermore, I used an abstract way of dealing with parent data in my open source Flutter Clock submission. If you are interested in understanding parent data better, it could be helpful. The abstract multi child (container) render object can be found here.
Simplification
You might not need to go that deep (depending on what you are trying to achieve).
You can also set parent data using a ParentDataWidget and potentially combine that with simpler ways of composing your shapes.
For example, you could just use a ClipRRect or something with a specific border radius and pass that border radius to the parent data. With some math, you will always be able to find the correct edges for your shapes with variable border radii in your multi child render object paint method :)
Abstraction
If you do not need to handle abstract cases, i.e. in your case all kinds of different shapes (which could be implemented using the parent data shape description as I outlined), you could also just leave out all of this.
Imagine you always use the same border radius. Why would you worry about even passing parent data then? You could simply calcuate where the edges are based on the size when you have a fixed border radius or fixed shape.
So I want you to keep in mind that even though I proposed this abstract way of dealing with it (which is not difficult at all to work with when you understand but can be cumbersome to get into), you should find the simplest way of solving the problem for your specific case.
More abstraction is always possible - I could e.g. pour a lot of effort into something like this, creating an extremely abstract API that can handle shapes of any kind (using PathMetrics e.g.) to always find the perfect spots, no matter what kind of cubics you used to paint your nodes. However, that might be completely unnecessary and even lead you off track because you are not able to handle the more difficult solution.
Approach 1: abstraction for all cases
If you are looking for something abstract, look at my canvas_clock implementation for inspiration - it uses basically only RenderBoxes, so you will find what you are searching for in that :) In hindsight, the code quality is not amazing, the structure was not well chosen, and it obviously glosses over hit testing, intrinsic sizing, etc., however, for what it does, it goes the way of the abstract extreme (:
Approach 2: pragmatism for a specific case
There are a bunch of exisitng abstractions (like ParentDataWidget and CustomPainter) that can be used instead and you might not even need to handle different shapes (just a bit of math if you e.g. always draw the same rounded rectangle).
If you are only interested in one specific shape, I think that most of the parent data stuff is not strictly necessary :)
Conclusion
I think that I presented you with a few approaches for how this could be pulled off. I did not go into any specifics (maths or how to do it using PathMetrics - hint: you can use one Path object for canvas.drawPath and also extract information using PathMetrics), however, that is due to the broad nature of the question.
I hope that this information was useful to you in any way - I sure did enjoy sharing my thought :)
Btw, I am sorry for the ramble. I would consider this a low quality answer because I only quickly wrote down my thoughts instead of thoroughly structuring the answer and conducting some more research.
I created a custom circle layer. I want to show this layer only on water and not on land. I managed to do the opposite (ie: showing the layer on land and not on water) using below command. Refer this image for better understanding
map.moveLayer('polygon','water');
Now I need to know the land layer which is used by mapboxgl so that I can call function map.moveLayer('polygon','land'); to achieve what i want.
I need help to find the different layers present in the mapboxgl-streets map. But unfortunately, Mapboxgl doesn't have map.eachLayer function.
You can use the Map#getStyle method to get a serialized representation of the entire style including the layers.
map.getStyle().layers
It depends on the map style you're using. In general, you either have to look at its source or load it in Mapbox Studio to identify the correct layer name. Also keep an eye on https://github.com/mapbox/mapbox-gl-js/issues/4173.
Just to add to Lucas' answer (which is still correct), map.getStyle().layers provides all layers in the style, including ones you have explicitly added (via map.addLayer()), and those that are included in the style (which could be a lot). Careful how you filter through these. For my case, I created arrays to hold the layers I created myself, to make future iteration simpler.
in a Cube, I have a calculated measure [Nb>4] depending on a measure [Nb], filtering only the values above 4.
We don't want users to see the underlying measure [Nb], so I defined a perspective which hides it using -[Measures].[Nb]
I am looking for a way to give access to a perspective without giving access to the cube it depends on... (because using xmla (Excel), users can currently see the perspective and the cube).
I tried to do that using the roles definition module, but it seems not to be possible.
You can define the 'default' perspective (see first image). This perspective is a special one that applies visibility to all cube.
It should be possible then to hide your measure
-[Measures].[Nb]