eclipsesource / graphical-lsp Goto Github PK

In the DiagramManager class we are currently rebinding the OperationService so that the sprotty DI container and Theia DI container are using the same singleton instance. However we have to check if the OperationService has been bound before (i.e. the client extension uses the paletteModule) otherwise the rebinding process fails and the diagram editor can not be started.

Issue should be addressed here:
https://github.com/eclipsesource/theia-sprotty

The initial implementation could reuse the existing Theia UI mechanism (e.g. context menu commands)
A more sophisticated approach could be implemented later (e.g. OS Week)

Prepare a pull request for the changes made to the theia-sprotty glue code to support GLSP

• Clean up theia-glsp module and refactor all glsp-specfic code
• Create PR

Currently the maven build of the server plugins is throwing a bunch of non-critical warnings. Before we integrate Travis CI (c.f. #34) we should try to get rid of most of these warnings

Is should be possible to edit the labels/names of components by double-clicking on the label.

After multiple addtions/deletions of connections sometimes an exection occurs (see below)
Seems to be a server side issue where the indexer for new connections gets out of sync and then creates provides an already existing ID.

root ERROR 2:13:14 PM widget-0_sprotty e: Failed to execute command: Error: Duplicate ID in model: edge:weighted5
at t.e.add (http://localhost:3000/bundle.js:1:64694)
at t.add (http://localhost:3000/bundle.js:19:113204)
at t.e.add (http://localhost:3000/bundle.js:1:64917)
at t.add (http://localhost:3000/bundle.js:19:113204)
at t.e.initializeRoot (http://localhost:3000/bundle.js:12:29766)
at t.createRoot (http://localhost:3000/bundle.js:78:1498076)
at t.execute (http://localhost:3000/bundle.js:12:402750)
at http://localhost:3000/bundle.js:30:559357
at new Promise ()
at http://localhost:3000/bundle.js:30:559291
root ERROR 2:13:32 PM widget-0_sprotty e: Failed to execute command: Error: Duplicate ID in model: edge:weighted5
at t.e.add (http://localhost:3000/bundle.js:1:64694)
at t.add (http://localhost:3000/bundle.js:19:113204)
at t.e.add (http://localhost:3000/bundle.js:1:64917)
at t.add (http://localhost:3000/bundle.js:19:113204)
at t.e.initializeRoot (http://localhost:3000/bundle.js:12:29766)
at t.createRoot (http://localhost:3000/bundle.js:78:1498076)
at t.execute (http://localhost:3000/bundle.js:12:402750)
at http://localhost:3000/bundle.js:30:559357
at new Promise ()
at http://localhost:3000/bundle.js:30:559291

Selecting a tool from the palette doesn't work reliably with multiple clients (probably related to the Operation Service handling).

Currently the diagram editor can be opened exactly once. Opening another diagram or reopening the previous diagram will result in an empty editor widget.
This is probably related to an incorrect (resp. non-existing) shutdown on server side and incorrect handling of multiple clients

Add and implement tools for node creation to the palette (see #4).
For now just focus on top-level creation and ignore the use-case of creating nodes inside other nodes.

Add and implement tools for creating connections to the palette (see #4). The server should provide so-called connections hints. With this connection hints the client knows which connections are allowed and which are forbidden

The protocol used by our GLSP implementation should be documented somewhere. We should probably fork https://github.com/ObeoNetwork/GraphicalServerProtocol to the EclipseSource domain and change the specfication.md file accordingly

The user should be able to delete a nodes and its connections from the diagram.

After migrating the repository to the EclipseSource organization we should probably also rename the Java packages of the server components. (at.tortmayr.glsp -> com.eclipsesource.glsp)

Currently the actions are reflectively collected based on the methods of the handler. We would like to change that so that we use DI:
DI Module has an Action Registry which specifies available actions
DI Module has an Action Handler which provides handlers for actions
if there is no handler, the server just logs that and doesn't do anything.
Clients may add additional actions.

It should be possible to reconnect edges by dragging the start/endpoint of the edge to another source/target.

For this the client should make use of DragAndDrop hints. These hints defined the allowed DnD actions and reduce the amount of necessary client-server roundtrips (similar to move hints #28)

Currently the move actions in the sprotty diagram are only client side changes and do not affect the model stored on the server. We have to forward these actions to the server and make use of server-provided move hints.

With these move hints the client only doesn't need to communicate with the server during the "dragging part" of the move process and only sends an update once the element has been "dropped"

Update architecture overview figure to reflect the current module structure/naming.

For JsonRPC Theia components exist which allow to start the server automatically. This is not the case for the standard sprotty websocket diagram server. However, Sprotty uses currently websocket in their server-communication component sprotty-theia.

Right-clicking below a GLSP diagram opens the context menu of the browser (not the Theia specific one) and, in addtition freezes some parts of the Theia application

EDIT: A workaround for this issue is to switch to another Theia view (e.g. problems view) This apparently allows Theia to "refocus" and the application is working again. So most likely this issue is related to some sort of focus problem

The connection tool should be reworked to draw a line instead of selecting source and target elements. (c.f. the connection tool of Papyrus)

Users should be able to resize elements, if indicated that elements are resizable (see SetBoundsChangeHintsAction. Note that there already is a SetBoundsAction which allows to set dimensions and location (see also MoveAction). Clearly, there is an overlap between those actions.

Imho, mid-term we could either drop the MoveAction and implement it based on the SetBoundsActionor we rename the SetBoundsAction into ResizeAction and keep MoveAction for clarity.

It'd be cool if we could host the example somewhere so that people can try it.

Before publishing this as open source, we should probably configure CLA check and change the namespace to com.eclipsesource.glsp (server).
Todo:

• Change namespace to com.eclipsesource.glsp
• Ensure that all source code file have the correct copyright header
• Configure CLA
• Change repository visibility to public
• Setup Travis CI

Once we close a GLSPDiagramEditor in Theia the application freezes (View-Switching to regain focus seems to work) and then the Diagram can't be opened again.
A quick investigation yielded the following:
The GLSPTheiaSprottyConnector isn't able to connect with the GraphicaLanguage client. The cause for this are probably improper shutdowns on both client and server side when closing the diagram.

The Filebased Modelfactory should probably be refactored. We should extract the saveModel() method from this class and make generic and stateless. (With passing the ModelState instead of the SModelRoot we should be able to access all required information for saving the model)

Seems like pom.xml of workflow-example project needs to set parent path (looks for parent only in direct parent directory?)

Currently, only the server can persist the model (see fix for #36 and default handler of the SaveModelAction). I do believe that both is a valid use case in general, however, following the usual LSP architecture, it is actually the client's responsibility to persist the model. I think it is fair that the server is still notified about the change, however, the client really performs the save then directly into the workspace.

Therefore, I think the SaveableGLSPModelSource should be capable of saving directly to the workspace. Clients should be able to enable or disable client-side save depending on whether the server or the client should be responsable for persistence.

In the fix for #36 we mark a model as dirty as soon as an executeOperation_* is sent to the server. However, this is not a very reliable mechanism. Without having thought this through entirely, imho, the server needs to decide whether a model is dirty or not; eventually, the server decides which action is actually performed or not, isn't it?

Instead of the currently used sprotty fork we want to use and extension on top of sprotty in the future.

This extension contains all the necessary features, services, modules etc. to use sprotty as a diagram render framework in a GLSP client.

We should have a look on how to properly configure VS code for mono-repositories to improve the current (flawed) workflow

This should probably be done after #25 and #24 are completed and merged to avoid reconfiguration.

If possible we should address the following issue

• proper and reliable watching of packages to avoid rebuilding for every change
• proper auto import for new type definitions
• Access to .ts sources of major dependencies (@theia packages etc.)

In addition, we should have look on how to improve the overall build times of this project #

To improve consistency the copyright headers in the .java and .ts source files should be updated to EPL2.0 (from EPL1.0).

A sprotty model object and view which enables rotated rectangles while maintaining the correct anchor position

We should implement a problem marker support for GLSP diagrams. (Similar to the problem marker support in Papyrus but for now a baseline and simplified solution suffices)

We should make use of the SelectionService hook introduced in 1674493 which enables listening to model changes.

For now it's probably best to create a simple json-forms based property view with edit capabilities

It would be awesome if every successful build of the master would publish the client npm packages with the "next" tag and deploy and publish the server maven modules in the snapshot repository. (i.e. nightly versions of our plugins)

This would allow dependent projects like coffee editor or ecore-glsp to use the latest versions without the constant need to publish a new release.

Currently it seems we are only dispatching a SelectAction with the last selected element instead of including all selected elements.

Currently we use client-side layouting by augmenting the diagram model with additional layout information. In the long run we should switch to a server-side approach. The original sprotty server implementation uses the Eclipse Layout Engine for this (ELK)

To enable better tracking of the changes made to sprotty we should integrate it as a submodule

• Fork from https://github.com/theia-ide/sprotty/ to the EclipseSource organization
• Integrate the fork as submodule
• Integrate the forked module into the yarn build
• Apply extensions,features and changes made for GLSP

I cannot build the current master 770d109. Seems to be a problem with the package configurations.

The border for selected nodes is not displayed properly. When hovering over a node the border gets empathized but when clicking to select it the border disappears.

This seems to be node specific as the (multi) selection of edges is working as expected.

Until our future PR for sprotty (c.f. #20) has been merged we should integrate a fork as submodule.

• Fork from https://github.com/theia-ide/theia-sprotty/ to the EclipseSource organization
• Integrate the fork as submodule
• Integrate the forked module into the yarn build
• Apply the changes made

File path sent to server for loading model is broken: Includes "/c%3A/" instead of "C:/". Needs fixing in com.eclipsesource.glsp.api.factory.FileBasedModelFactory.convertToFile(String)

Check if problem comes from Theia or GLSP Client

The user should be able to delete a connection from the diagram

Currently we have to start the GLSP manually in an Eclipse instance. This is no issue during development and enables easy debugging however we should probably also provide a packed fat-jar of the glsp server which the client can start automatically in its backend process. (similar to the LSP startup in yangster https://github.com/theia-ide/yangster/blob/master/theia-yang-extension/src/backend/backend-extension.ts)

We would then also need two different startup configurations for the browser-app

• yarn start == Default startup where the client instantiates the language server in its backend

• yarn start:debug == Startup for development/debugging where the client simply receives the port on which the glsp server is running

The current logging approach on server side is a messy mix of log4j logger and System.outs.
The whole logging should be migrated to log4j only

Currently the canvas of the diagram editor only uses about half of the actual space available in the diagram widget.
This might be a remain of the original sprotty-xtext implementation which used a split screen approach for diagram and textual language.

Currently the actual rendering of model elements is handled entirely on client side. This results in a couple of issues:

• No generic clients are possible. Each client must have knowledge about the actual diagram language implementation so that it can provide the corresponding views. This contradicts with the basic idea of GLSP and is no real solution to the matrix problem

• The GLSP diagram can look vastly different depending on the implementation. Using server side rendering would ensure similar looking diagrams across different client implementations

Sprotty has already an element type for prerendered SVGs which can be reused for this issue

To avoid permanent client-server roundtrips during a semantic move action the client should maintain a set of move hints. With these hints the client knows which movements are allowed and only has to inform the server once the move action is finished (i.e. the server gets notified once the element has been dropped and the entire "drag process" is handled on client side)

Currently an edited diagram can only be persisted by invoking the save command via the Diagram->Save menu.

We should integrate this action properly into Theia (save on close, saving via ctrl-s etc.)