Zest 2.0

[ptziegler]

Motivation

Throughout the migration from SWT to FX, Zest received several bugixes, as well as a (from my perspective) cleaner API. With https://github.com/fsteeg/zest, containing the latest version that is still using SWT, we now have the unique opportunity to reintegrate those changes.

Goal

• Full integration of Zest Layouts, Core, JFace and CloudIO, but not DOT (due to dependencies to XText/EMF).

• Backwards compatibility with Zest 1.x layouts: Layouts are the bread and butter of Zest. Downstream projects should be able to use their custom layouts without requiring major changes.

• Preservation of new Zest 1.x features: Our own implementation of Zest has evolved throughout the years and now contains functionality that never existed in Zest 2.0. Those features must not be removed.

Non-Goal

• Source and binary compatibility. As indicated by the increased major version, classes may be renamed, moved our outright deleted.

Tasks

• Reintegration of Zest 2.0 via Reintegration of Zest2.0 fork #410
  • CloudIO
  • Core
  • Example
  • JFace
  • Layouts
  • Tests
• Removal of internal references to deprecated API
• Update of documentation
• Due dilligence process for new contribution

Following classes will be marked for removal and are no longer considered API:

• Filter
• LayoutEntity
• LayoutItem
• LayoutIterationEvent
• LayoutRelationship
• LayoutStyles
• NestedLayoutEntity

[azoitl]

@ptziegler thx for this very nice summary on re-integrating Zest 2.0. Should we announce this also on the GEF and maybe also on the cross-projects mailing lists to get a wider reachability of this news.

[ptziegler]

Should we announce this also on the GEF and maybe also on the cross-projects mailing lists to get a wider reachability of this news.

It'll probably still take a few months before everything is done, so I think that's a little premature. But it makes sense once the updated API is somewhat cleaned up and functional.

[azoitl]

It'll probably still take a few months before everything is done, so I think that's a little premature. But it makes sense once the updated API is somewhat cleaned up and functional.

Ok that is a good point. I thought more as a pre-anouncement that Zest users can get a a heads-up.

Should we set-up a dedicated branch for that work?

[ptziegler]

Should we set-up a dedicated branch for that work?

The branch already exists. A lot of the classes overlap with one another, so I don't think it's possible to reintegrate #410 without also addressing the API which is why everything has to be done in one go.

I thought more as a pre-anouncement that Zest users can get a a heads-up.

Which is something we should certainly do. I just don't see that there is anything more to say than "We'll eventually move to Zest 2.0".

[ptziegler]

Which is something we should certainly do. I just don't see that there is anything more to say than "We'll eventually move to Zest 2.0".

Hopefully I can make some time to continue working on this again tomorrow or within the next few days. Once I have a rough idea I can also draft an email.

[azoitl]

Should we set-up a dedicated branch for that work?

The branch already exists. A lot of the classes overlap with one another, so I don't think it's possible to reintegrate #410 without also addressing the API which is why everything has to be done in one go.

I thought more like a feature branch in this repo here. So that we can work in parallel and merge it back to master when its ready.

I thought more as a pre-anouncement that Zest users can get a a heads-up.

Which is something we should certainly do. I just don't see that there is anything more to say than "We'll eventually move to Zest 2.0".

I was also not sure what to announce.

Hopefully I can make some time to continue working on this again tomorrow or within the next few days. Once I have a rough idea I can also draft an email.

If I can support you in any way. Let me know.

[ptziegler]

I've thought about the whole ordeal and also went through some of the bugs related to the previous Zest 2.0 update.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=283179
https://bugs.eclipse.org/bugs/show_bug.cgi?id=283083

In short, there was a general concern regarding backwards compatibility and API breakage, which is why it was proposed to do the update in two steps.

In the first step, Zest Layouts is updated to 2.0 but in such a way that it doesn't cause API breakage in Zest Core. And I think that's something worth pursuing.

With the latest changes, I've (hopefully) reintegrated everything that came from the Zest 2.0 fork and marked everything as deprecated which should not be carried over. Zest Core remains at 1.x.

I thought more like a feature branch in this repo here. So that we can work in parallel and merge it back to master when its ready.

I suppose that makes sense. In that case I would push the current state as a starting point and everything else is then done via pull requests.

If I can support you in any way. Let me know.

The worst part is probably done already :) Though there are some parts that broke due to this update (and were already broken on the fork), so if you can find the time to review some of the fixes, you'd already help out a lot.

[ptziegler]

Also a few words regarding backwards compatibility: With the current implementation, the graphs support both Zest 1.x and Zest 2.x layout algorithms. Given that the API is completely different, I have done this by moving the old code to dedicated subclasses.

For example, you have now a GridLayoutAlgorithm, which uses the Zest 2.x API and a GridLayoutAlgorithm.Zest1, which contains the old and unmodified implementation. At the few places in the graph where we actually perform the layout, we check the type of the layout algorithm and then call the matching "applyLayout()" method.

Clients that only use the default layouts would automatically switch to the new API without having to do any additional work. And in case they have defined custom algorithms, they would first have to enable the legacy mode by implementing/extending the "Zest1" classes and then switch to the new API in a second phase.