Graduate to version 1.0?

[spoenemann]

I'm thinking about graduating from the incubation phase. I'd like to gather feedback about changes in the code that you would like to see before such a step. This is particularly important for breaking changes: better do them now than after a 1.0 release.

Things I would like to do before 1.0:

• Finish and merge migration to snabbdom 3 (#227)
• Consider reducing the number of repositories (create a monorepo)
• Review the API and data structures

[planger]

Thanks for your initiative! I'm all for it and happy to support this great step.

I'd find it great if we could get #226 too. Also @Aksem is working on an integration of libavoid with Sprotty via a webassembly port of that library. This integration should probably live in an optional separate package, but it requires a few minor additional changes to the router API on top of #226, which imho would be good to have in an 1.0 release.

[CamilleLetavernier]

Hi, I've created a new issue (#232), which may also slightly affect the API, and would probably make sense before the 1.0 release. I will provide a PR for that

[tortmayr]

Sounds like a great idea! :+1: API-wise I think there are a couple of points we should discuss before the 1.0 release.

• In PR #226 Miro raised the question wehter we should refactor the action API to use interfaces instead of classes. I opened #233 to track this. Even if we decide to not move away from the class-based approach we should at least ensure that all action have a proper guard function and use them over instance of checks.
• In #33 we introduced a Tool (manager) API to support enabling and disabling tools (i.e. mouse listeners) at runtime. This API is heavily used in GLSP but currently not used in sprotty at all. We should discuss how to go forward with this. Is the Tool API still generally interersting for sprotty? If so, should we start to migrate the existing tools (e..g 'MoveMouseListener')? If not, maybe we should move this API from sprotty directly to GLSP.
• When introducing the UIExtension API (#63) the question was raised wether we should refactor the Popup stuff to an UI-extension based approach (https://github.com/eclipse/sprotty/pull/63#pullrequestreview-205640214). If we still want to do that we should probably also do it before the 1.0 release.

[spoenemann]

Thanks @tortmayr! Could you create issues to track discussions about the second and third point as well?

I think both points would require an analysis of feasibility and consequences of a refactoring.

[spoenemann]

Another question is how many (breaking) changes we want to include in the 0.10.0 release. One approach could be to do as many changes as possible before that release so we can test the framework properly before going to 1.0.

[tortmayr]

Thanks @tortmayr! Could you create issues to track discussions about the second and third point as well?

I think both points would require an analysis of feasibility and consequences of a refactoring.

The second and third point are now tracked in #235 and #236

[NiklasRentzCAU]

I just had a look at the tickets I created in the repositories, looking for any more severe issues. I stumbled upon #149 again. As I see exporting diagrams as a core feature that we like to use a lot for documentation, this only working in Chrome and not in Firefox or VS Code extensions limits its use. So far I did not have a deeper look into the implementation to pinpoint this inconsistent behavior between the browsers. However, I think this should be tackled before a 1.0 release.

Furthermore, for your point of "reviewing the API and data structures" I would also support a more complete documentation of these as well. Multiple of my students have worked on projects using Sprotty now and the lack of proper API documentation and comments in the code made some tasks for them harder than they should have been. I know you are aware of this issue, maybe this could be a good time to resolve that, especially if more people are starting to use Sprotty in VS Code and standalone applications.

[christoph-fricke]

Since the potential release of 1.0 sparked some activity in Sprotty, I would like to direct some of the attention to sprotty-vscode as well. Currently, there exists a bug in the library (see: https://github.com/eclipse/sprotty-vscode/issues/42) where the webview is not cleaned up correctly when a singleton webview is used. The bug occurs when a user opens a diagram view for one fileUri and closes it for another. Afterwards, the webview can no longer be opened for the initial fileUri, because it is not correctly removed from the internal webviewMap, and sprotty-vscode tries to access the disposed webview panel. This is super annoying and confusing for users who do not understand what is happening internally.

[spoenemann]

FYI I scheduled release 0.10.0 for October 21: https://projects.eclipse.org/projects/ecd.sprotty/releases/0.10.0

After that one, we can go more deeply into preparations for the graduation release. Any help on that is appreciated, both for the formal process and code cleanup / restructuring.

[spoenemann]

The graduation review was concluded successfully: https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/570