What's the DiagramWidgetRegistry and why is it gone in v0.6.0?
In Theia, there used to be an EditorRegistryonly, so we copied it more or less to access diagrams in a similar way. As Theia has a WidgetRegistry now, we use that.
@/all I made a PR that adds a very basic feature: the ability to dispatch requests in the client. eclipse/sprotty#103
It digs quite deep into the base architecture, please review!
Also please assign the current milestone (v0.7.0) whenever you fix any issues. We’ll use that for the changelog, which we’ll start maintaining with the next release.
It would be nice to release v0.7.0 before ECE (October 21)
Hey guys, I was wondering for some time now, why the svg generation is called each time the diagram is drawn. Every move or zoom of the diagram will cause Sprotty to call the generation again, although it could just keep the old svg and put a different transformation around it. This would be much quicker because the svg just has to be rendered new and not generated, which for bigger diagrams just makes it feel laggy when zooming or moving.
@JanKoehnlein I think the automatic publishing of the npm packages is failing again. On https://www.npmjs.com/package/sprotty only 0.8.0-next.ff11b36 from 16th of Oct is available, even though there have been a couple of commits on master since then. Is there something I can do to retrigger? Thanks a lot in advance!
Seems to be a failing test on our publishing server.
1) ThunkView "before all" hook for "renders on change": Error: Timeout of 5000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/var/jenkins_home/jobs/sprotty/jobs/sprotty-next/workspace/src/base/views/thunk-view.spec.tsx)
In the long run, it would be cool if we could publish from the Eclipse servers. If you want to help implementing that, that would be great.
I increased the timeout to 10s (!) Seems to work. I guess at Eclipse we'd have faster servers
@JanKoehnlein Great, thanks a lot for fixing the build! We're currently setting up the publishing process from the Eclipse servers for GLSP, so I guess, once this is done, we can let you know how it went and see if it can simply be adapted to Sprotty as well. (cc @tortmayr)
Just wondering, is there any ETA on a 0.8.0 release?
@tivervac Not yet, do you have some special issues you need to have fixed?
I think most of the issues we need fixed are already merged, there's just no release with them in it yet
@JanKoehnlein As discussed a few weeks ago, @tortmayr outlined how we set up the NPM and Maven publishing from the Eclipse infrastructure in order to resolve the timeout issue preventing the publishing to npmjs. @tortmayr outlined the necessary steps here: eclipse/sprotty#150 Does this help? Is this something you would like to pursue? I'm happy to help in any case.
Hi All. Is there an example of how a label can be anchored to different points on an edge as opposed to the center?
Hi all, I just found sprotty via the examples of elkjs and find it pretty interesting. As the project I'm currently working on is written in React (with Typescript), I'm curious to know, if there is some kind of an example for a React integration. I saw that this somehow was mentioned in the old repo (theia-ide/sprotty#203).
I would like to do a sprotty release in coordination with the next Theia release, such that we have a compatible released version of both. Theia is likely to release next Thursday. Any opinions?
@JanKoehnlein Sounds great, thanks! :+1:
hey, did anyone experiment with deploying sprotty through github-pages ?
Kreyren @Kreyren is having hard time with the deployment atm
Kreyren @Kreyren is also slowly losing a mind trying to make a class diagram in using sprotty in theia
Kreyren @Kreyren me is eating chocolate, is depressed and gave up for today
Good things come to those who wait: I've released sprotty 0.8.0 (incl. sprotty-server, sprotty-theia, sprotty-elk, sprotty-vscode and the theia-xtext-sprotty-example). Please upgrade and let me know if there are any problems.
@JanKoehnlein \o/ Thanks a lot!
It seems that support for older ELK versions has been dropped?
@tomvdbussche I think the dependency on ELK is not “hard”, i.e. you can safely force an earlier ELK version. The ELK API is very stable.
Jan set a fixed version just to avoid having a version range (some folks seem to be allergic to that in Java world)
Is that true for the OSGi as well? Afaik their versioning is a lot more strict
That might be, and version ranges are much more common in OSGi. If it turns out to be a problem, we can change the OSGi dependency to a range.