gaphor
Disallow free-floating ports for SysML
Describe the solution you'd like
1, Ports cannot exist without a container, so creating a port not as part of a "block" should be disallowed. 2, When a port is added to a block, it shall be added to the outside line. 3, When a port as part of the block is being moved, it shall move only around the border, not inside or outside.
The way you describe it, it looks a lot like Parameters on Activities: edit delete parameters in the Property Editor. Are you proposing a similar approach for ports?
I would simplify the possible actions a user can do to the following:
Adding a new port:
- Select a port icon on the toolbar
- Click outside a non-block element's boundary: nothing happens
- Moves the mouse to the boundary of the block: show rectangle. Clicks: display port on the edge.
- Moves the mouse inside the block and clicks: add ports to the edge.
To move a port around:
- Drags a port at the edge: can be moved only around the edges. Not inside, not outside.
To remove a port:
- Click on the port and press delete or anything alike.
Click outside a non-block element's boundary: nothing happens
I think it's weird to let nothing happen. We should at least provide feedback to the user.
A ProxyPort is only created in the model when a Port (item) is connected to a block.
I think we just found another problem.
Create a block. Select proxy port. Click on the diagram outside the block. I will see a port being displayed free floating. It is although not associated to a block, that is true, but I would argue that a port cannot exist (displayed) on a diagram as NOT part of a block.
I agree that a port has no value, unless it's connected to the border of a block.
I propose we make the interaction similar to what we currently have for Parameters on Activities.
I tried out the parameters on activities and it wasn't intuitive to be honest. I started looking for the activity parameter on the toolbar, but did not find it, and then I by mistake clicked on the activity and then I saw, okay, this is how I can add a new parameter.
The current functionality is great, the only thing you need to do is to disallow adding a port to a diagram alone.
We could also do something with color. For example make the port red if it is not connected.
(just thinking through some options)
I would say a solution that is well designed shall not allow invalid states. In my opinion having a free floating port is an invalid state, therefore it shall not be achieved. By not allowing it will simply cut down the "and what if" complexity. What do you think?
The underlaying mechanism is similar to the issues you describe in #2484, and #2481.
The elements in the model are only created when the pin/port/relationship is properly connected. The underlaying model is always consistent.
I do not think Gaphor should be very restrictive/prescriptive in that respect. A user should be able to move a relationship aside and reconnect it at a later point. The model is in an "invalid state" for a while.
Also, what is valid and not valid depends on the methodology you follow. SysML is only a generic language.
I think we should treat validation as a separate (opt-in) topic.
Validation can currently be achieved with:
- CSS: change the visuals of unconnected elements
- Create a validation module in Gaphor (as a plugin) that checks for model validity.
In my opinion this is not a need from a modeler point of view. I never wanted to reuse a connection during the years I have been doing modeling, and in the usability it causes me personally more harm than good, because I mistakenly tend to disconnect pins/edges and then I have to reconnect them which goes really against my user experience. It is especially painful when working on a laptop, using a touchpad.
In my opinion it is both a philosophical question and a UX (user experience) question as well. What I suggest here is to get the community involved more and ask their opinion, and/or make some video recording about how people would use the tool and ask them to comment their feelings so that we get realistic feedback.
I agree that constraining the port once it has been connected to the block to the boundary of the block would greatly improve the ability to align them.
It also isn't consistent with Parameter Nodes on Activities, which @amolenaar pointed out. I propose we make them match, then a future feature could be adding ports and parameter nodes to the toolbars for drag and drop, if we think that is a better user experience (I'm unsure of this or not to be honest).
I propose we make them match
What do you mean by match? Provide port functionality similar to how Parameters on Activities work? Or allow Parameters to be added via the toolbox?
In my opinion both functions shall be available.
- For an action there should be a way to add ports by using a tabular structure
- Also for an Activity parameters there should be a way to add parameter from the menu using drag and drop
For this first step, I propose we add ports using the tabular structure, which is how Parameter Nodes work.
And make them not disconnect, as Parameter Nodes do.
I suppose we should give a similar treatment to Pins (in activity diagrams).
Making the node pins not free-floating is a really good idea. At the moment moving a node pin slightly off its line causes it to disconnect and lose its label which is frustrating because you often want to move them up or down, if they behaved like parameter nodes that would solve this problem. Additionally, you can copy/paste text into the right-hand side window much quicker than you can drag the node pin.
@amolenaar how should we progress with this? In my opinion we should just simply remove the capability to disconnect a pin, and it solves most of the problems in usability and we can simply close this task.
I have to check how it's done for Parameter nodes. Effectively, if you refuse to disconnect, it should stay connected, but we should also check if it works if you delete a pin.
From the user point of view, when working with an action having pins, it is extremely easy to disconnect a pin, especially when using a laptop. I see no use case where a modeler wants to disconnect a pin: either he wants to move it on the edge of the action in order to make the diagram look nicer or remove it altogether.
From the user point of view, when working with an action having pins, it is extremely easy to disconnect a pin, especially when using a laptop.
I had the same experience when I was playing around with it a bit.
https://github.com/gaphor/gaphor/issues/2484#issuecomment-1646857560 I made a proposal under the related issue. I think it can be applied to the ports as well and would solve a part of what has been discussed under this issue.
This ticket is almost solved, the only thing we are missing is to disallow adding a pin to a diagram without an action as a parent.
Here's what I would probose to do with these floating ports. It was also discussed in Element app about async validation which is in itself much larger issue. Let us agree whether what I propose is what we want so I can implement it (while taking consideration your refinements); or if not, then lets close the issue.
@sz332 @amolenaar Please review:
- When clicking on pin/port in the toolbox, the active diagram grays out everything that the pin/port can not be attached to.
- When clicking on the diagram while the pin/port tool is active, new floating pin/port item is added to the diagram and it can be dragged around.
- When releasing the pin/port item and it is not attached to anything, the diagram removes the item and displays notification that pin/port can only be attached to
- and was removed automatically.
Refinements (2) gray out still is active while dragging to guide the user to do valid things. (3) we can also add setting to control this behavior if someone finds it undesireable.