eclipse-sprotty / sprotty Goto Github PK

When an edge has an arrow head, we have to adjust the anchor point with respect to the stroke width and angle of the arrow head. Currently we store this correction values in the SModel (SRoutableElement#sourceAnchorCorrectionand #targetAnchorCorrection).

We should consider fetching these values from the view, as that is where the arrow head is defined.

The CssClassDecorator overwrites existing styles. It should add styles instead.

Currently, you can move nodes and routing points to every position in the diagram. This results in a very smooth UX, but makes it hard to align nodes with each other.

We should add an infrastructure to help aligning nodes to some magnetic positions, be it based on other nodes or a grid.

Remove

• SModelStorage: SModels are often to big to be put on browser local storage.
• DiagramState / ExpansionState: dirty UI state can just be stored in the SModel (internal model) now
• IStateAwareModelProvider: doesn't make sense anymore

Constructor injection induces much more API breaks than necessary. We should prefer property injection whenever applicable.

As can be seen https://developer.mozilla.org/en-US/docs/Web/Events/dblclick, the double click event 'dblclick' is a MouseEvent and not a WheelEvent, but it is typed as a WheelEvent at least here, here, here and here.
This is a minor problem, as it can be cast to the correct type when used.

   isCompartmentSchema(schema: SModelElementSchema): schema is SLabelSchema {
        return getBasicType(schema) === 'comp';
    }

looks wrong (shoud be schema is SCompartmentSchema)

In the class diagram example, select an edge: no handles appear.

We could adopt a few guidelines from Theia. In any case we need to document the Eclipse legal requirements: signing off commits and signing an ECA.

The resulting CONTRIBUTING.md should be copied to the other Sprotty repositories as well.

#46 introduces dependency injection for commands and views. We should consider applying the same approach to action handlers.

Hi @JanKoehnlein @spoenemann,

I'm looking into using sprotty within theia in order to create a small demo to visualise a git repository. I don't necessarily need a language server aspect as I can mock most of the data if required. Do you have any thoughts or pointers on how to get started to use it within theia?

I tried to follow documentation, examples but it wasn't always straight forward or up to date so any help is greatly appreciated.

Thanks!

For use cases of Sprotty that support editing, it would be nice to also have a UI allowing the user to conveniently edit labels directly in the diagram. I've created an initial implementation that adds a new labelEditUiModule which reacts to the existing EditLabelAction and then provides a UI based on the UIExtension introduced in Sprotty a while ago. When the user confirms the edit, it sends out a ApplyLabelEditAction which can then be processed according to the specific use case. In GLSP we would forward it to the server in order to apply the modification, or you could have a local command just applying it to the SModel, or be forwarded to the textual language server.

Are you, in general, interested to have that in Sprotty directly? As it doesn't put any restrictions on how the label edit is actually be applied (on a server or local), the implementation is rather agnostic of the use case.
The implementation is not perfect yet, but I guess it wouldn't be too much work to brush up the code for Sprotty.

Please let me know what you think.

Hi, i recover this issue from theia-ide/sprotty repository: theia-ide/sprotty#240
My problem is a bit different: I have a Vue (not using TypeScript) project using sprotty to draw an Elk generated graph.
I have found various example to configure and use Sprotty but all use TypeScript, so, I used the Elk Graph Viewer sample to implement a "bridge" library in TypeScript that configure Sprotty and then I use it in Vue project, and it work well.
I have been able to implement the issue solution (implementing IActionHandler) in this "library" but I cannot figure how to "send" the action content back to the Vue project, or how to configure a custom function to handle the event from Vue project. Basically I only need the id of selected node(s)
Is it possible? There is some example for this?
Thank you very much for any help

This line of code is executed on any selectable element on mouseDown:
https://github.com/eclipse/sprotty/blob/8b297c58f19ce6f6f1c5ccfa2d49fbff8cf24ce8/src/features/select/select.ts#L211

This causes a SelectAction to be issued. I think this is too early and the SelectAction should be issued on mouseUp if the mouse has not moved after its last mouseDown.

Imagine the following case: We have non-draggable but selectable diagram elements represented by a textual file in an xtext grammar (Similar to some parts of the yangster example). Clicking on the diagram ist mostly used to just drag the entire diagram canvas around to browse within the diagram.
We do not want the element that the mouse happens to be clicking while dragging to be selected because that causes the text file to select the corresponding code via tracing and other more specific behavior that happens when an element is selected. The editor switching its cursor is really unwanted in that case.

At least in such a case the SelectAction really should only be sent on mouseUp, but I know from your other examples (such as theia-xtext-sprotty-example) that the selection is important to be happening during mouseDown already so that moving around the selected elements works.

An idea I have is to maybe separate the mouseDown and the mouseUp selections or introduce some other action that can be listened to to differentiate between these two usages.

Committing the internal model back to the external one could be asynchronous. We should enable that.

With eclipsesource/graphical-lsp#136 we proposed a command palette for GLSP. In GLSP we will fill this command palette with editing actions that come from the server (similar to code completion in LSP). However the base is independent of that as it obtains all available actions from a dedicated DI-configurable action provider.

Is that something that you would welcome in Sprotty as well? If yes, we could extract the GLSP-independent part and move this to sprotty.

Here a short screen cast how the initial implementation looks like:

Some feature modules depend on others, e.g. the moveModule depends on the routingModule.

We should make that explicit and simplify the composition of the DI container, e.g. by automatically sorting modules or automatically including dependent feature modules. Maybe we should even check for cycles.

We should also move graph into features while we're at it.

When there is an edgePositioning: move it along the line.
Otherwise: move it freely.

With big diagrams, scrolling and zooming gets very slow as we recalculate and patch the entire tree.
We should add so kind of shortcut for changes that just affect the viewport.

The KeyTool currently only supports listening to the 'keydown' event but we would also need to listen to the 'keyup' event.

From theia-ide/sprotty#219:

When applying zoom-to-fit, edges may not be visible because they are not bounds-aware and thus not considered. This problem might apply to other features, too (e.g. SVG export).

There should be

• a default routing if no routingPoints are defined
• an editing mechanism that keeps the edge rectilinear.

Currently the micro layout is applied during the hidden rendering cycle before the macro layout is applied. If the macro layout decides to further increase the size of an element, e.g. to ensure there is enough space for the contained elements or the connected edges, the micro layout is not invoked again. This can lead to inconsistencies: for example, if a node label is configured to be centered, it will end up not being in the exact center in such a scenario, since its position has been fixed after the micro layout run.

When using sprotty in an UI framework like Theia, some user interactions are triggered outside of the sprotty architecture, e.g. keystrokes or drag and drop. You sometimes need to access certain properties of the SModel in order to turn these into sprotty actions, e.g.

• transform a screen position into a diagram coordinate (needs Viewport)
• access the selection

While within sprotty, event listeners can access the SModel, these external listeners can't.

For other cases, such as bounds, we often process certain action in the model source and keep the external model updated. External listeners can then get the current values from the model source. Unfortunately, this doesn't seem to be a viable solution for viewport actions such as center, as the necessary calculations and the update of the viewport happen directly in the respective command.

As a second solution, on can implement some kind of pre-action and a pre-command that gathers the necessary information and issues the real action. This sounds a bit complicated, but is safer as we don't make assumptions which actions change the needed properties.

A third solution would be to implement services, like a selection or viewport provider, that get the values directly from the current model in the command stack. This kind of breaks the encapsulation we had.

From theia-ide/sprotty#216:

The viewer should accept an array of models in updatePopup. Furthermore, the computation of hover positions should be moved away from the HoverMouseListener into a separate service class.

I realized that the command palette is placed incorrectly in different contexts. This can be reproduced, for instance, by removing the bootstrap css import from the class-diagram.html example.

This issue caused by the offsets of the parents of sprotty's base div so that the absolute positioning either takes the browser's page as their coordinate system's origin or sprotty's base div.

We should therefore find a computation of absolute positions of e.g. UI extensions that works for any HTML context the Sprotty base div might be placed in.

Sprotty is using CSS to style diagrams. This is very useful to interactively change some styling aspect in the diagram using the style editor in browser. Unfortunately, this stops at layout options, whcih are currently defined in as LayoutOptions in the SModel. The disadvantages of this are

• tuning the node/edge layouts has very long turnarounds
• the SModel blows up, which is problematic for client/server communication
• to compensate we sometimes adapt the SModelFactory which adds further complexity,
• we intoduced a cascading mechanism to collect the layout options by spreading them all values from the root to the current element, which may not scale well.

We should consider getting the layout options as CSS variables. We'd get

• using the browser's internal and optimized capabilities for merging styles
• interactive layout editing as with other styles
• a better separation of concerns
• a much smaller SModel.

The only problem may be that we have to listen for CSS changes in order to trigger a relayout. AFAIK we can only add change listeners to the direct CSS properties of the element. We'd maybe have to trigger the relayout manually, e.g. on a certain keystroke.

See theia-ide/sprotty#135. Edges should have a special layout that allows children to be positioned along the line with a factor between 0 (source) and 1 (target). Additional options should be longitudinal (with the line) and latitudinal (across the line) offsets and whether the child shall be rotated with the line.

From theia-ide/sprotty#195:

In the class diagram example, the initial node positions are reapplied every time a node is expanded or collapsed.

Support nesting of nodes with compartments. The padding of the inner nodes area shall be computed from the compartments bounds.

Especially when providing editing support, but also in other scenarios, it is useful to support enabling and disabling diagram tools, such as a node or edge creation tools, deletion tools, but also for non-editing scenarios, e.g. a special selection tool (for instance allowing to draw a rectangle with the mouse and every element that intersects will be selected). In traditional diagram editors, the enablement and disablement of tools is typically controlled by the user via a palette.

Currently, there is no dedicated infrastructure to control the enablement of tools in Sprotty. Tools are usually registered via DI, typically in the form of key and mouse listeners, and then remain active throughout the lifecycle of the diagram widget.

Therefore, we introduced a ToolManager in the graphical-lsp framework, which keeps a list of available tools and which manages their state. The tool manager itself is controlled via an action handler that reacts to dedicated actions (e.g. EnableToolsAction), so palette implementations can enable or disable tools by sending those actions. On each action enablement or disablement, the tool manager initializes or disposes the respective tools, which allows them to register and unregister their listeners, as well as to perform any arbitrary diagram modifications, etc., such as setting it up for visual feedback in the diagram, etc. that can later be cleaned up when the tool is disabled. To accommodate for the typical scenarios, the tool manager supports two types of tools, standard tools and "other" tools. Standard tools become active in the common user-interaction state until other tools are explicitly activated. Once a tool is finished or the user escapes the current interaction mode, all standard tools can be activated again.

We think this infrastructure might be interesting for Sprotty in general and not only for the graphical-lsp use case. If you agree, we'd be happy to open a PR. Please let us know what you think?

Several diagram notations, such as flow charts, use nodes shaped in the form of a diamond / rhombus with an independent width and height. This new node should provide proper anchoring support of connected edges taking the shape of a diamond and its height and width into account.

This issue has been originally raised and discussed in theia-ide/sprotty#235.

From theia-ide/sprotty#218:

We have several actions that appear in request / response pairs:

• RequestModelAction / SetModelAction
• RequestPopupModelAction / SetPopupModelAction
• RequestBoundsAction / SetBoundsAction
• RequestExportSvgAction / ExportSvgAction

We should add a mechanism that allows to match a response to a corresponding request. This is necessary in case multiple actions of the same kind are fired at the same time.

The command palette introduced with #34 only disappears on blur (e.g. if the user clicks somewhere else). Especially since this is a keyboard-oriented way of invoking commands, we should also allow to hide the palette on Esc.

These very different concepts, so they should have different names. Suggestions welcome.

From theia-ide/sprotty#220:

One can get lost by zooming extremely far in or out or by panning far away. It should be possible to configure limits on how far one can zoom and pan.

If a FitToScreenAction with a padding is dispatched, the zoom level is wrong regarding the height. It looks like parenthesis are missing:
https://github.com/eclipse/sprotty/blob/579bee34577f2243a36fc178c6bef9debc9116ea/src/features/viewport/center-fit.ts#L198-L200

I'll open a PR in a sec.

In Firefox-Browser to move a node, you have to select a node first, then mouse-up, then you're able to move the node.

We need a mechanism to disable editing, e.g. when the underlying model is invalid.

Some actions in sprotty-theia cannot be serialized, i.e. because they contain a reference to the workspace. They have to be handled on the client only. We should mark these somehow and maybe come up with a generic handler.

Steps to reproduce:
In the theia-xtext-sprotty-example, let StateNode#canConnect return always false
-> on reconnect, the edge is created in the diagram, but not in the model. The edge should not be created in the model either.

There is a lot of docs in the wiki we could use as a start

I was trying to run the examples on my local machine, but nothing shows up. The log outputs that bundle.js is missing (404). I also find bundle.js listed in .gitignore. Is that intended? So how I can test the examples? Especially the mindmap since its not in here: (http://sprotty-demo.typefox.io/examples/index.html)

From theia-ide/sprotty#71:

Currently we queue all animations. Even though they are short, this can yield to quite a bunch of screenplay when events are fired faster than the resp. animations are running.

We should investigate how to make at least some animations cancelable. The following animations should then start from the cancelled state instead of the targeted final state of the cancelled animation.

We should have something like this

  "main": "lib/index",
  "types": "lib/index"

so consumers of our library can import from sprotty instead of sprotty/lib.

See https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html

They still contain the java stuff, and they are not usable (SVG) without a server.
Mindmap doesn't work at all.

Currently, we create views and commands directly using the constructor. That causes problems when you want to use a specific service, that is usually provided (and as such configurable) using DI. Our current workarounds are

1. Add the service to the RenderingContext/CommandExecutionContext. While this is OK for services from Sprotty's base modules (e.g. ViewRegistry), but causes a dependency cycle when a downstream module wants to contribute something (e.g. graph or some feature).
2. Add the service to the SModel, as we did for SEdge#route() or the anchor calculation. This turns the internal model into an object-oriented API, while the rest of Sprotty rather follows a service-oriented/functional pattern. We're loosing all the nice declarative properties of the SModel.

In the particular case I am currently trying to solve, I want to provide different edge routing strategies based on a property of the edge. I need these strategies in the view as well as in the command, but there is currently no way to inject a EdgeRouterRegistry into these.

If we create commands and views using DI, we will solve all of the problems generically and have a much clearer architecture. Chances are high that we can hide the heavy-lifting with InversifyJS behind existing Sprotty APIs.

The API changes would include

• the registration of commands (maybe)
• make all commands and Views @injectable
• turning anchor calculation into a service

See theia-ide/sprotty#143. UpdateModelCommand should animate changes to edge routing points.