eclipse-glsp / glsp Goto Github PK

https://github.com/eclipse-glsp/glsp-client/blob/ed5d776ccb12ae3eb48b4641941ae93c0a6a06fa/src/features/select/selection-service.ts#L51

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

see also #15
[migrated from https://github.com/eclipsesource/graphical-lsp/issues/37]

It seems this is caused by a failing usage of UUID.

In some scenarios a specific SVG text may be have the focus when hitting Ctrl+C which leads to the condition below to be false:

https://github.com/eclipse-glsp/glsp-client/blob/27b2c49d181505265aaf9d3f8dee0a9c5d6d32a2/src/features/copy-paste/copy-paste-handler.ts#L101

We should find a better way to test whether the GLSP copy should be active or not. Probably it is better to trigger the GLSP copy unless the srcElement is a child of a UIExtension.

We didn't migrate yet the test cases, such as https://github.com/eclipsesource/graphical-lsp/tree/master/server/glsp-graph/src/test

At the moment, minimum size layout options (minimum width, minimum height) are not considered when elements are resized.

Furthermore, when resizing elements smaller than their size they start to change position as well. This is unexpected behavior and should be corrected.

The contribution guide needs to be updated to reflect the branching name schema we want to use as well as how a commit message should look like.

Clicking on SVG elements doesn't update the document selection. In the context of diagramming with GLSP, this is unnatural, as the user would expect that clicking in the diagram (e.g. to select a diagram element) would clear any other selection state in the DOM. From a technical point of view, an active selection in the document after clicking into the diagram may also lead to bogus target elements in certain browser events, such as clipboard events, etc.

https://github.com/eclipse-glsp/glsp-client/blob/master/src/features/hints/type-hints.ts

By default, we should at least order them alphabetically. Also, we should first sort by sortString and then alphabetically (if the sortString is the same).

Something like the command-palette but usable in other contexts, such as label-editing, etc. Ideally, this widget should support different modes, such as only selecting from existing elements, or allowing to enter expressions that are validated.
The shown suggestions should be retrieved from the server via context actions endpoint. The validation of a free-text expression will usually also take place on the server.

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

see also eclipsesource/graphical-lsp#26

We should start adding end-to-end tests (UI) that verify the correct behavior of using the example diagram from a users-point of view.

In glsp-client, I think at least the following classes should be unit-tested:

• src/features/context-menu/menu-providers.ts
• src/features/layout/layout-commands.ts
• src/features/select/selection-service.ts
• src/features/hints/type-hints.ts
• src/features/change-bounds/movement-restrictor.ts

Maybe also other more complex commands would be worthwhile to test. Several other aspects are likely to be easier tested with UI end-to-end tests based on glsp-examples.

What do you think?

When performing multiple operations quickly on the client, they may stack up on the server before they are being successfully processed. During this time, the client- and server-diagram is out of sync (e.g. for ChangeBoundsActions) or operations are not reflected yet in the diagram (e.g. DeleteNodeActions).

It would be good to visually indicate to the user, if actions are still pending on the server. We may want to use a revision numbering; i.e., knowing the current revision number, the client increments its local revision number by the number of the invoked operations and the server indicates the revision number (its starting revision + number of performed operations) in the model update. While there is a diff between the revision number of the last model update from the server and the local revision number kept by the client, operations are still being processed on the server.

Ideally, the client may even show the number of pending changes and even assigns CSS classes to the elements that have been modified but are not yet processed (e.g. assign a CSS class indicating that this element is waiting to be deleted, has been moved but not yet processed on the server, or even adding a ghost element to indicate that an element creation is in process).

The implementation of this feature might be related to https://github.com/eclipse-glsp/glsp-server/issues/5

see eclipsesource/graphical-lsp#303

I tried the following in the Jenkinsfile

            parallel {
                stage('Maven build') {
                    steps {
                        sh "mvn clean verify"    
                    }
                }
                stage('Checkstyle') {
                    steps {
                        sh "mvn checkstyle:check"
                        recordIssues(tools: [checkStyle(reportEncoding: 'UTF-8')])
                    }
                }

But it seems this isn't supported on the Eclipse Jenkins. I receive the following error:

java.lang.NoSuchMethodError: No such DSL method 'checkStyle' found among steps [archive, bat, build, catchError, checkout, container, containerLog, deleteDir, dir, dockerFingerprintFrom, dockerFingerprintRun, echo, emailext, emailextrecipients, envVarsForTool, error, fileExists, getContext, git, input, isUnix, junit, library, libraryResource, load, lock, mail, milestone, node, parallel, podTemplate, powershell, properties, pwd, readFile, readTrusted, resolveScm, retry, script, setGerritReview, sh, sleep, sshagent, stage, stash, step, timeout, timestamps, tm, tool, unarchive, unstable, unstash, validateDeclarativePipeline, waitForQualityGate, waitUntil, warnError, withContext, withCredentials, withDockerContainer, withDockerRegistry, withDockerServer, withEnv, withMaven, wrap, writeFile, ws] or symbols [all, allOf, always, ant, antFromApache, antOutcome, antTarget, any, anyOf, apiToken, architecture, archiveArtifacts, artifactManager, artifactsPublisher, authorizationMatrix, batchFile, booleanParam, branch, brokenBuildSuspects, brokenTestsSuspects, buildButton, buildDiscarder, buildingTag, caseInsensitive, caseSensitive, certificate, changeAbandoned, changeMerged, changeRequest, changeRestored, changelog, changeset, checkoutToSubdirectory, choice, choiceParam, cleanWs, clock, cloud, command, commentAdded, commentAddedContains, concordionPublisher, configFile, configFileProvider, configMapVolume, containerEnvVar, containerLivenessProbe, containerTemplate, credentials, cron, crumb, cssText, cssUrl, culprits, default, defaultView, demand, dependenciesFingerprintPublisher, developers, disableConcurrentBuilds, disableResume, docker, dockerCert, dockerfile, downloadSettings, downstream, draftPublished, dumb, durabilityHint, dynamicPVC, emptyDirVolume, emptyDirWorkspaceVolume, envVar, envVars, environment, equals, expression, faviconUrl, file, fileParam, filePath, findbugs, findbugsPublisher, fingerprint, frameOptions, freeStyle, freeStyleJob, fromScm, fromSource, gerrit, git, gitHubBranchDiscovery, gitHubBranchHeadAuthority, gitHubForkDiscovery, gitHubSshCheckout, gitHubTagDiscovery, gitHubTrustContributors, gitHubTrustEveryone, gitHubTrustNobody, gitHubTrustPermissions, gitParameter, github, githubPush, globalConfigFiles, headRegexFilter, headWildcardFilter, hostPathVolume, hostPathWorkspaceVolume, hyperlink, hyperlinkToModels, inheriting, inheritingGlobal, installSource, invokerPublisher, isRestartedRun, jacocoPublisher, jdk, jdkInstaller, jgit, jgitapache, jgivenPublisher, jnlp, jobName, jsUrl, junitPublisher, kubernetes, label, lastDuration, lastFailure, lastGrantedAuthorities, lastStable, lastSuccess, legacy, legacySCM, list, local, location, logRotator, loggedInUsersCanDoAnything, masterBuild, maven, maven3Mojos, mavenErrors, mavenLinkerPublisher, mavenMojos, mavenWarnings, merge, modernSCM, myView, never, newContainerPerStage, nfsVolume, nfsWorkspaceVolume, node, nodeProperties, nonInheriting, none, not, onFailure, openTasksPublisher, override, overrideIndexTriggers, paneStatus, parallelsAlwaysFailFast, parameters, password, patchsetCreated, pattern, permanent, persistentVolumeClaim, persistentVolumeClaimWorkspaceVolume, pipeline-model, pipelineGraphPublisher, pipelineMaven, pipelineTriggers, plainText, plugin, podAnnotation, podEnvVar, podLabel, pollSCM, portMapping, preserveStashes, privateStateChanged, projectNamingStrategy, proxy, queueItemAuthenticator, quietPeriod, rateLimitBuilds, recipients, refUpdated, requestor, run, runParam, sSHLauncher, schedule, scmRetryCount, scriptApproval, scriptApprovalLink, search, secretEnvVar, secretVolume, security, shell, simple-theme-plugin, skipDefaultCheckout, skipStagesAfterUnstable, slave, snapshotDependencies, sourceRegexFilter, sourceWildcardFilter, spotbugsPublisher, ssh, sshUserPrivateKey, stackTrace, standard, status, string, stringParam, swapSpace, tag, text, textParam, tmpSpace, toolLocation, topicChanged, triggeredBy, unsecured, upstream, upstreamDevelopers, userSeed, usernameColonPassword, usernamePassword, viewsTabBar, weather, wipStateChanged, withAnt, withSonarQubeEnv, zfs, zip] or globals [currentBuild, docker, env, params, pipeline, scm]

The commands are sometimes executed in the wrong diagram widget.

see also: https://spectrum.chat/glsp/general/trying-to-add-new-menuitemprovider~03147a72-b129-40f8-9fbc-46c63105720e

We have to be careful with the usage of Arrays.asList() and the util methods for empty collections (e.g. Collections.emptyList()). This methods return immutable (or fixed-size) collections and should not be used in classes that could potentially be subclassed/customized. As an example:
Extending a default ActionHandler, overwriting the executeAction method and simply adding a new action to the result of the super call will throw an UnsupportedOperationException.

As a common guideline I'd propose that we generally use Lists.newArrayList() (provided by guava) instead of Arrays.asList() and create new empty collection objects instead of using Collections.emptyList()

Arrays.asList()/Collections.emptyList() should only be used in special cases where we explicitly want to define unmutable collections.

The existing codebase should be updated accordingly.

This is a follow-up issue of #24

Sprotty now provides an extension for VSCode (https://github.com/eclipse/sprotty-vscode).
It might be interesting for us to adapt this glue code to support GLSP diagrams in VSCode

Currently there is no feedback at all. If the glsp server is not running the diagram (widget) just remains empty. At least some sort of error message should be prompted to indicate that something went wrong.

In many scenarios, we'd like to provide suggestions / auto-completion while a user is editing a label. This is for instance useful for type completion, etc.

We already provide a suggestion / auto-completion mechanism for the command palette, which has been pushed down to Sprotty. Also we already have a mechanism for label edit validation.

Therefore, what is missing is to create a label edit UI that extends Sprotty's command palette. The UI input should be built on the same UI as the command palette, to simplify styling and have a consistent UI look. However, it should have a separate own suggestion provider that can be implemented locally or from the server, similar as we do it with the command palette suggestions. On the server, an own handler registry and handler interface needs to be created for edit label suggestions. The context information for the server must include the label ID, so that the server knows which suggestions to load (e.g. the ones for a particular attribute or for a reference).

Once this is done, implementors only need to do the following to benefit from this feature in their custom editor:

• in the client-side di container, bind the enhanced edit label UI module that also provides suggestion / auto-completion based on a suggestion provider over the default plain edit label UI from Sprotty. This module should do all required rebinds that may be necessary to replace the default edit label UI from Sprotty.
• implement and bind suggestion providers on the server

The command palette should also support sort-of dynamic commands for creating new elements.
In particular, we are interested in creating new elements by specifying name and type.
(e.g. typing MyName:AutomatedTask should create a new AutomatedTask with the name label "MyName")

[migrated from https://github.com/eclipsesource/graphical-lsp/issues/265 ]

This is to simplify modifying and testing multiple packages.
Also check if this works with watching all packages.

Reduce amount of casting/type checks by use of Generics.
Maybe:1-to-1 mapping between action and corresponding handler?

[migrated from https://github.com/eclipsesource/graphical-lsp/issues/371]

Goals of this Dockerfile:

• Easily run the example
• Potentially also simplify development (yarn linking, no NPM requirement for host machine, etc.)

https://github.com/whitecolor/yalc

After the 0.8.0 release the dependencies from sprotty-theia changed from "next" to a fixed version. This looks like a bug to me and should probably be changed back to next. I opend eclipse-sprotty/sprotty-theia#58.

If this is intended we have to update our repositories accordingly or rely on yarn resolutions.

For now this means that all glsp-examples builds are failing. Hopefully I get a response from jan soon otherwise I have to implement a temporary fix
@planger FYI

The GModelIndexImpl uses EMF's ECrossReferenceAdapter for being able later to resolve incoming references (such as GEdge#target). However, the cross-references are processed while the adapter is recursively added to each EObject.
As we use the index for resolving the source and target cross-references' values of GEdge the crossreferencer tries to verify whether the source and target features are actually set and therefore tries to obtain the value. As this happens while the cross reference adapter is being added recursively, at this time not all nodes may have been processed. Thus, we may be unable to find the source or target based on the ID and index at this time, so that the cross-reference is later neglected (as the cross referencer thinks the value is not set).

I suggest that we fall back to a model search while the cross referencer is still "setting targets" (ie is in the process of adding itself as an adapter to all model elements).

This feature seems currently not or only partially implemented and causes a lot of issues if a concrete implementation tries to use it.

Most of these issues are related to inconsistencies between the revision state held in memory by the server and the actual model revision.

[migrated from https://github.com/eclipsesource/graphical-lsp/issues/283]

A generic point that we should start thinking about is to make it clear (by package name) what is internal and public API meant to be directly used and extended by clients. This will give us more flexibility in the future when doing modifications as we'll know what we can change without affecting existing language-specific client implementations.

[migrated from https://github.com/eclipsesource/graphical-lsp/issues/363]

Ideally, the client would correct the position on creation, and the server would double-check and do the same.

Layout actions introduced in #266 do not respect the settings for "no-element-overlap" (see #259). If this option is activated elements cannot be moved "above" other elements. This is not the case when layout commands are used.

[migrated from https://github.com/eclipsesource/graphical-lsp/issues/271]

Resize handles can always be moved freely even if a Snapper instancer (e.g. CenterGridSnapper) is bound

After the API refactoring (#18 ) it's no longer possible to handle multiple elementTypes with one CreateOperationHandler. This is rather restrictive and might affect some GLSP-based projects (e.g. EMF.cloud Ecore Tools)

When a client invokes an operation, we typically have the following interaction scheme, if client-side layout is switched on:

C --> S: ExecuteOperationAction
   |
C <-- S: ComputeBoundsAction
   |
C --> S: ComputedBoundsAction
   |
C <-- S: UpdateModelAction

If the client invokes multiple operations in a short time, it may happen that the second operation invocation is sent before the UpdateModelAction from the first operation has arrived. This may lead to strange behavior in the diagram, as it may seem to the user that the second, third, ... action is undone. This is because the "visual feedback" of a ChangeBoundsAction (client-side local move) is first applied on the client and is then reset by the UpdateModelAction sent by the server before it is applied again by a following UpdateModelAction.

A possible approach could be introducing an action queue on the server and waiting for the ComputedBoundsAction from the client before a next incoming action (if it is an operation) is processed. This queue would ensure that the operations are not processed before the entire interaction scheme is completed. However, it may not be sufficient to avoid resetting and reapplying the actions caused by multiple ChangeBoundsActions that lead to sequential UpdateModelActions. Therefore, we may have to batch those operations (skipping the UpdateModelAction).

Currently when the server sends a ServerStatusAction the client shows this as a status in the widget and as a message. But these two things are quite different in their usage:

• There can only be a single widget status at a time and the user is not able to remove them.
• There can be multiple messages at any given time and the user is allowed to remove single messages.

Furthermore, an OK status from the server currently clears the widget status but leaves any opened messages untouched. Additionally, currently when the user opens a message with details and closes either the message or the details dialog, we clear the widget status.

The goal of this task is to disentangle these two concepts and allow the server to send separate actions for messages and widget status. The clearing functionality should still be available but, again, for both concepts separately.

[migrated from https://github.com/eclipsesource/graphical-lsp/issues/137]

This would allow the client to ping the server and if it's not alive then the client can start a new server instance from a local jar.

Similar to how this is handled in https://github.com/eclipse-emfcloud/emfcloud-modelserver

Copy/cut & paste is an essential feature of a diagram editor and should be supported by GLSP.

As in the GLSP architecture the server is responsible for performing diagram manipulations, also the cut & paste operations, which actually make changes to the diagram, are to be performed on the server. In order for the server to know which actions are to be performed, the server should also be in charge of deciding what to put into the clipboard based on the selection, so that it can later on paste derive from the clipboard data what needs to be changed. Thus the client should ask the server for the data to be put into the clipboard on copy/cut and later send this clipboard data back to the server on paste.

As we need to ask the server to determine the content that we want to put into the client's clipboard, we'll have to workaround the issue that the traditional browser clipboard API doesn't allow to write into the clipboard asynchronously. The new async clipboard API has support for that, however, it requires a permission given by the user. If we want to support the traditional API, we need to store the server-sent clipboard data in the client separately and not in the clipboard. Alternatively, we may investigate using the new clipboard API.

Usually the application frame, e.g. Theia, has general support for copy, cut and paste actions, which we'd generally like to be able to integrate with also for GLSP copy/cut & paste. Therefore, I suggest to add a copy/cut and paste handler into the GLSP client framework that is invoked by the specific copy/cut & paste mechanism by the application frame, such as the glsp-theia-integration. This way a standalone GLSP editor could invoke this handler directly from a keyboard listener while a Theia-based editor could have copy/cut & paste listeners for Theia that invoke the handler.

The GLSPDiagramManager must increase its priority because it is otherwise overwritten by eg @theia/editor-preview. I suggest to use a value of 1000 or higher.

• Move issues
• Add documentation to contribution.md etc. that issues should only be filed in glsp
• Maybe add github issue templates that again indicate that issues should go into the parent glsp repo

This method seems worth testing:
https://github.com/eclipse-glsp/glsp-client/blob/ed5d776ccb12ae3eb48b4641941ae93c0a6a06fa/src/features/change-bounds/movement-restrictor.ts#L69

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

see also eclipsesource/graphical-lsp#35

The workflow standalone example has become outdated and needs some love.
We need to check if everything still works and in addition add missing features that have only been added to the theia-integration at this point.

Identified issues:

• JSON-RPC protocol definition is only in theia-integration although the GLSPWebsocketDiagramServer in client is also JSON-RPC based (including method for server initialization)
• Copy-paste not working
• Layout-commands are only implemented in theia-integration
• Context Menu integration?
• Saving the diagram not working
• Dirty state marker?

Currently we use latest but should use a fixed version.

Currently the ActionProcessor delegates an action to the first suitable registered ActionHandler. This behavior is contradicting with the implementation on client (sprotty) side where an action is delegated to all suitable handlers ( in sequential order)