As mentioned with the NatTable 1.1 release, we planned to stop active development for the 1.x architecture. This decision was made because of several issues we see with the current architecture. Our plan was to focus on the 2.x architecture, which mainly meant to reimplement everything new.

We skipped that decision because of several reasons, mainly because it would be too much work in one step. Also we are aware of the growing user base of the NatTable 1.x architecture, and we want the NatTable community to grow further, to get more interested parties, contributors and committers, which will make such changes easier to staff.

The current idea is to perform a smooth transition from the old architecture to a new one. This is not possible for all changes, like event handling and offset rendering calculation to name a few. But for some of the major changes it looks like a good idea.

Although it will be possible to introduce some architectural changes into 1.x without breaking too much, there will be API changes users will have to follow. But with that smooth transition, users of NatTable 1.x are able to follow and will not have to implement everything new with the new architecture at first hand.

Below you will find the ideas on the roadmap for NatTable. I would like everyone to participate in a discussion about that. Also raise your hand if you like to help with the implementation or anything else regarding the future of NatTable.

The following is a first draf of a roadmap for the future of NatTable:

NatTable 1.2

Abstract out direct SWT dependencies
To support multiple UI toolkits it is necessary that the rendering calculations are independent of SWT. For this we will introduce interfaces to operate on, while the concrete implementations will be wrapper on UI toolkit classes that are served via factory.
This will have impact on users code for configuration of styles, listeners and menus. We will provide helper methods to make the code changes as easy as possible.
The following classes will need to be wrapped:

GC

Point, Rectangle

Color, Font, Image

Menus

Dialogs

Editor controls

NatTable Canvas inheritance

UI bindings (mouse and keyboard listener)

DnD support

To add support for other UI toolkits, the wrappers will use resolution independent rendering (e.g. JavaFX uses doubles for pixel coordinates).

Extract the SWT dependent implementations to a new extension.
Doing this will change the installation process, as a new extension needs to be installed in order to render a NatTable.
This will also enable additional UI toolkit support.

Remove painter states
Several painters have their own states additionally to the current styling, e.g. height/width calculation configuration in TextPainter. These states should all be style attributes so it is possible to completely style a NatTable declarative instead of creating different instances of painters.

Update NatTable dependencies

Update to Eclipse Helios (Bug 413208)

Remove Apache Commons Lang dependency

NatTable 1.3

Introduce dependency injection

Every NatTable instance will get its own DI context (in Eclipse 4 this means its own context in the DI context hierarchy).

Support for several DI container/frameworks like Eclipse 4, Guice and Weld.

It should be possible to add NatTable to an application that already uses DI (e.g. Eclipse 4) by using the existing container, without introducing new dependencies.

It should still be possible to run NatTable in applications that doesn't use DI. In such cases NatTable will need to have its own container that is independent from the rest of the application.

Only support already globally used instances like ConfigRegistry, UIBindingRegistry or the current active cell editor for dependency injection in this phase.

The above are just the first two main steps towards the new architecture. Implementing them in the current architecture will ensure the transition to the new architecture isn't a change with high costs for users and will ensure stability.

The following refactorings will need to be done to move to the 2.x architecture, where not all changes are yet planned or verified to work in the future:

Extend the DI mechanism to also support creation and connection of layer compositions

Refactor internal event handling

Currently events and commands are mutable. This is causing strange side effects sometimes.

Refactor ILayer interface to be smaller (e.g. create helper classes to provide general functions that doesn't need to be implemented all the time)

Support really huge data sets (long ranges)

Correct client area and offset calculation

Implement unique cell identification without the need for index-position-transformations

Add a configuration language and a corresponding editor to compose a NatTable

Additional tasks that can be done in parallel could be:

CSS styling engine

Refactor column grouping

Add accessibility support

Add support for lazy loading data and also remove items from memory on scrolling (e.g. Disposing images) for better memory handling. (scroll listeners)

Refactor cell size configuration, remove SizeConfig from DataLayer and make it available in a global scope

Move GroupBy interfaces and abstract implementations to NatTable Core, so it is also available using other list implementations

Refactor LabelStack to implement itself the Collection interface which makes the usage easier

Refactor configurations to follow the triangular concept of registry, ui bindings and layer (command handler) concept for every layer

Please start the discussion on the NatTable roadmap. Feel free to add additional ideas or contact us if you want to take a task.

Of course we would also welcome sponsors, which would enable us to spend more time on developing the future of NatTable.

The plans for the 2.x architecture are particularly interesting ! For me, the most interesting improvements are:
- the DI for registries;
- the unique cell identification;
- the decrease of the size of the ILayer interface;
- and finally the language/editor for the build of the NatTable.
The remove of the dependency to Commons Lang seems also to be good.

The most complex part of building a NatTable for the first time for a developer is to understand in which order the layer stack must be defined: you may have configuration/rendering issues if the layer stack is not well defined. So it could be very interesting and increase the usability of the NatTable if some tips could be available in the proposed editor.

Finally, I agree with your proposal to make a "smooth" update with 1.2 and 1.3 releases. It is very important for companies where upgrades of components are not done if the changes are too big. And we will have time to update tutorials

The NatTable is a great component, and the feedbacks from the users are very positive, especially on the "GroupBy" feature! And the development time is greatly reduced compared to a "simple" table.