[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[gef-dev] Draw2d/GEF 4.0

Hi all,

I had tried to start a discussion on whether to have a new major version of Draw2d and GEF in 2012 here recently. As there has not been much response yet, let me clarify what I was referring to in detail, because that could probably have been misunderstood.

Having worked on Draw2d and GEF for some while now, I have come to the conclusion that it would be nice to have the chance of adjusting some of its API. I am not talking of a major redesign here, but there are lots of (often minor) issues, whose proper adjustment would make it necessary to break current API. Consider e.g. the introduction of different scaling factors for x and y in ScalableFigure. As the ScalableFigure interface provides a method to return the single used scaling factor (getScale()) it would be hard to align this with the introduction of different scaling factors for x and y. Another example would be the very tight coupling of SelectionManager and AbstractEditPartViewer (consider the internal methods within SelectionManager), which is only there because AbstractEditPartViewer exposes its focusPart and selection, and which could be easily decoupled in case the fields in AbstractEditPartViewer could be made private. There are quite a couple of similar examples (especially the extensive use of protected/public fields in several places is causing problems, which could only be properly dealt with by reducing the visibility of the fields, when trying to evolve the code). 

Despite such kind of refactorings, it would be nice to have the chance of properly building in new stuff (which sometimes makes an adjustment of the current API necessary as well). Consider e.g. support for the newly introduced gestures in SWT 3.7, for which we would have to extend EventDispatcher (another dispatch method would have to be added, which is already a breaking API change) if we want to build it in properly. Proper support for rotation would be another example, there are others as well. While it may sometimes be possible to incorporate such changes while preserving the current API (e.g. by introducing a ScalableFigure2 or an EventDispatcher2 in the preceding scenarios), I would not prefer such an approach as it will lead to the degeneration of our code base and may hinder clients from adoption.

While I would thus like to have the chance of adjusting our current API, I see two important arguments that cannot be neglected:

1) we need to provide long-term support for our clients. This implies that - as GEF has been API-stable for quite some time now - we cannot simply come up with a 4.0 revision in 2012 without having announced it in advance and having given our long-term clients the chance to transition to it.

2) we most likely cannot achieve to incorporate all changes in a 6-9 month timeframe, so introducing a 4.0 version as a replacement for 3.7 in 2012 would be no good option from this viewpoint either. Being a replacement, we would have to fix its API again and would - to incorporate all changes - probably have to come up with additional major releases shortly afterwards.

Having talked with Ian about what he and Fabian intend for Zest 2.0 (namely to make it available in parallel to Zest 1.x and to consider its API to be provisional until it has matured and may replace Zest 1.x), I think this could be the way for Draw2d/GEF 4.0 as well. I.e. we could start to work on a 4.0 branch after Indigo release, considering all of its API to be provisional at first. Such a branch could live in parallel to GEF 3.x for a timeframe of 2-3 years (or even longer if needed), so we could continually work on a new major version without having to fear that we break existing clients. If we consider it stable enough, we could fix its API and communicate to clients that we recommend them to transition, deprecating the 3.x branch in turn.

Cheers
Alexander

--  
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nyssen@xxxxxxxxx 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus