eclipse-glsp / glsp Goto Github PK
View Code? Open in Web Editor NEWGraphical language server platform for building web-based diagram editors
Home Page: https://www.eclipse.dev/glsp
License: Other
Graphical language server platform for building web-based diagram editors
Home Page: https://www.eclipse.dev/glsp
License: Other
Currently we use latest
but should use a fixed version.
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.
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)
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
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 ChangeBoundsAction
s that lead to sequential UpdateModelAction
s. Therefore, we may have to batch those operations (skipping the UpdateModelAction
).
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.
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).
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
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.
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 ChangeBoundsAction
s) or operations are not reflected yet in the diagram (e.g. DeleteNodeAction
s).
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
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:
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.
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.
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.
Goals of this Dockerfile:
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.
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)
[migrated from https://github.com/eclipsesource/graphical-lsp/issues/137]
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.
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]
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
Ideally, the client would correct the position on creation, and the server would double-check and do the same.
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]
This is a follow-up issue of #24
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
Resize handles can always be moved freely even if a Snapper instancer (e.g. CenterGridSnapper
) is bound
We didn't migrate yet the test cases, such as https://github.com/eclipsesource/graphical-lsp/tree/master/server/glsp-graph/src/test
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:
The commands are sometimes executed in the wrong diagram widget.
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 ]
It'd be cool if we could host the example somewhere so that people can try it.
see also eclipsesource/graphical-lsp#35
In glsp-client, I think at least the following classes should be unit-tested:
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?
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).
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:
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.
This is to simplify modifying and testing multiple packages.
Also check if this works with watching all packages.
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]
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]
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:
GLSPWebsocketDiagramServer
in client is also JSON-RPC based (including method for server initialization)It seems this is caused by a failing usage of UUID.
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.
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.
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]
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]
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.