-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: for color of edges and ports. #3
base: main
Are you sure you want to change the base?
Conversation
I am a little unsure how such an RFC would continue. In this case, it would be reasonable to just implement a solution and display the outcome to visualize how this would affect the general look and feel of the diagram. Are there any general arguments against options for more color? |
@a-sr Do you mind taking a look at this? @lhstrh If I remember correctly, I should tag anyone that might be interested in this RFC and make them a reviewer. Currently, I think I do not have the rights to add reviewers to this PR. Should I just tag people, should I be able to add reviewers, or is either annoying? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking the time to write the first RFC (even though the process is not established yet)! I think this is a great topic for an RFC.
I don't fully understand the proposal yet. Is the idea to have a fixed color for all output ports and a fixed color for all input ports? Or can we change color per port? How does color work in conjunction with connections? Is this just about coloring the highlighted connection, or about assigning colors to connections generally? I think a sketch of the diagram would be really helpful for understanding the proposal.
I think tagging people is fine. The shepherd can add reviewers explicitly if needed (I'll take on this role for this PR). Also, we can only add organization members as reviewers, so will have to resort to tagging for external reviewers anyway. Also tagging @mkhubaibumer |
The edge selection style can be changed by either changing what the Note that this will only highlight the corresponding elements that were clicked. |
Co-authored-by: Christian Menard <[email protected]>
The LF-Logo uses orange (rgb(247, 148, 30) if I am not mistaken) and a blue that may be too dark rgb(0, 49, 100). In the image above I used dodger blue (which is the SCCharts highlighting color if I am not mistaken) rgb(30, 144, 255). |
In VS Code we could also use the highlighting color of the current color scheme. I think that this would only work, if the diagrams would use the VS Code color scheme, so this might be future work here. |
Here is a small list of all diagram elements that I know of that can be clicked and need interaction with suggested interactions: startup/shutdown/timer/reset
reaction/reaction label/mutation/mutation label
reactors/reactor label
action/action label
port/port label
edge
model models
reaction order edge
dependency edge:
Please add additional elements or selection interactions that I missed or that you have a different opinion about. |
@OmerMajNition do you have further suggestions for this? |
My idea was that when you interact with (e.g., Alt + Click) an element (e.g., a reaction, a connection, a port) you would could light up all components that exert causal influence on it or vice versa -- basically all causality chains that it is a part of. This would give you a sense of what other parts of the system it interacts with. I realize, however, that this could quickly become complicated/overwhelming as this would conservatively have to include paths that go through subsequent reactions in the same reactor (because these could interact via state variables. I guess we should ask ourselves whether we care more about soundness or completeness of the feature... |
Agree with Marten, changing color of whole causality chain would get complex. One simple thing that we can allow is, user should be able to select multiple lines at a time (ctrl + click a connection). Next selection shouldn't cancel previous selection. This would let users manually select desired data path. |
Question from @cmnrd : Should we add an option for "Colored highlightling" to the sidebar? Currently, I think this is not necessary, since I do not know when we would need a highlighting that is not recognizable (since it is only a thick black stroke/line) instead of a black/gray stroke/line (which may already be thick). Has anyone opinions on this? |
To implement this, we need a way to get the the actual element associated with a Rendering that we clicked on:
And depending on whether this is a KEdge or KPort or whatever (KLabel and KText currently have no selection highlighting), we want to do highlighting. |
According to my knowledge this is exactly how you should be able to get the (incoming and outgoing) edges of a port, via its The rendering of that edge should then be accessible from that edge, so that should not be your problem. |
I am doing this wrong. I am only changing the static selection style of elements defined in the synthesis, why is ok for the standard approach if I want to highlight the element that I clicked. To highlight elements that were not clicked, I need to catch and forward the |
Co-authored-by: Marten Lohstroh <[email protected]>
@NiklasRentzCAU has a better idea: We can add an action as it was done for the SelectRelatedAction here. This means we add and implement an action that is added to all elements that should be selectable in the synthesis and register it here together with the other action. What is missing it how one could alt+click to select multiple elements. The implementation in osgiviz only selects one element and resets the selection on click. The switch case should for LF not look at the view model element but has to consider what "real" LF model element might be inside to it to find the correct elements. |
This should also serve as a demonstration to show what a short RFC that is mainly a discussion about a few lines of code. Please have mercy on my spelling (even though it is mentioned in the guide, I did not carefully consider what to put in here).
Notes to the process:
I spend a lot of time reading the documentation. Maybe we would shorten it a little?