Patrick Ziegler

> However while writing this I had a second look. In all methods where you would update the selection with a null EditPart an NPE would allready be thrown there....

> 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...

> 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...

> 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...

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...

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...

As suggested, I've pushed the Zest 2.0 branch to this repository via #476. I think the current state is something that can be merged, though I think only for the...

Given that the PR only slightly exceeds 1000 lines threshold, I've requested a review from the EMO team: https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/15699 This contribution should be fine _I suppose_, given that we're effectively...

But we're effectively try to merge https://github.com/fsteeg/zest, which is a fork of the original GEF/Zest repository. My concern are the contributions that have been made outside of the Eclipse project,...

The PR has been approved and the pre-announcement is out. There are still some minor things I want to clean up over the next few weeks but otherwise, I think...