Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gef-dev] GEF3 resurrection

Hi Piere

On Thu, 2022-02-17 at 10:18 +0100, Pierre-Charles David wrote:
> Le 16/02/2022 à 17:11, Serge Rider a écrit :
> > Hi Team!
> >
> > I am from the DBeaver development team (https://dbeaver.io). We
> > develop the universal database management tool based on the Eclipse
> > RCP platform.
> > Besides other Eclipse RCP extensions, we heavily rely on legacy
> > GEF/draw2d.
> >
> > I was a speaker on several recent Eclipse Cons, the last session was
> > about legacy GEF adoption:
> > https://www.eclipsecon.org/2021/sessions/diagrams-eclipse-rcp-back-future
> > https://www.youtube.com/watch?v=3ZIUB2XFDLE
> >
> > What we want is to resurrect GEF3 maintenance and include it back to
> > the standard Eclipse RCP lifecycle.
> > We have several PRs we'd like to merge in the codebase (currently we
> > maintain all fixes in our forked repository on GitHub). We also want
> > to propose legacy API improvements (keeping  API backward
> > compatibility) and several features.
>
>
> Hi.
>
>
> This is great news, thanks for the initiative Serge! (Thanks for DBeaver
> btw, I use it almost every day and it's a great tool).
>
> As the maintainer of GMF Runtime, I'd like to remind that *a lot* of
> projects depend on GEF Legacy (via GMF Runtime or not). In the SimRel
> alone there's Graphiti, Sirius (and Capella, even if it's not in the
> SimRel), Papyrus, Ecore Tools, and probably others.

This is an good point, which shows how important it is to revive GEF Legacy. In my more then 10 years of GEF Legacy usage I regularly pass by the repos of this
projects and look for inspiration how certain things are solved. There also noticed fixes and improvements we should upstream to GEF Legacy. But I don't want to
point at others the same happened in Eclipse 4diac and therefore I hoped for an initiative like Serge's to happen. I was just to afraid to do it by my self.

>
> Of course improvements would be welcome, and we (in GMF and Sirius) may
> able to propose some fixes/improvements we've currently had to make in
> our own copies of GEF classes like you, but care must be taken not to
> break the many projects which depend on the current behavior (sometimes
> in subtle ways).

As written above it would be amazing to have GMF and Sirius on board on this endeavor. And you are right we really have to be careful here. But on the other
side it is great chance to get all GEF Legacy based tools on a new level.

Looking forward to the new future of GEF Legacy,
Alois


>
> Regards,
> Pierre-Charles David




>
> _______________________________________________
> gef-dev mailing list
> gef-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/gef-dev



Back to the top