Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » NatTable » Discussion: NatTable Roadmap
Discussion: NatTable Roadmap [message #1389215] Fri, 27 June 2014 13:54 Go to next message
Dirk Fauth is currently offline Dirk FauthFriend
Messages: 2902
Registered: July 2012
Senior Member
Hi everybody,

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

Greez,
Dirk & Edwin

[Updated on: Sat, 05 July 2014 07:41]

Report message to a moderator

Re: Discussion: NatTable Roadmap [message #1395900 is a reply to message #1389215] Mon, 07 July 2014 15:12 Go to previous messageGo to next message
Danny Tramnitzke is currently offline Danny TramnitzkeFriend
Messages: 25
Registered: April 2014
Junior Member
Hi,

do you have a date or time window already, when NatTable 1.2 will be released?

Regards,
Danny
Re: Discussion: NatTable Roadmap [message #1396022 is a reply to message #1395900] Mon, 07 July 2014 19:24 Go to previous messageGo to next message
Dirk Fauth is currently offline Dirk FauthFriend
Messages: 2902
Registered: July 2012
Senior Member
Note that this topic is intended to be a discussion and not an announcement.

It is intended to raise more interest in NatTable. But it seems that idea failed.

So the answer to you question in short is: No
Re: Discussion: NatTable Roadmap [message #1397470 is a reply to message #1396022] Wed, 09 July 2014 19:34 Go to previous message
Alain Bernard is currently offline Alain BernardFriend
Messages: 15
Registered: November 2013
Junior Member

Hello,

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 Smile

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.

Alain



Previous Topic:Selection of row after grouping is done
Next Topic:Lazy loading tree, multiple columngrouping
Goto Forum:
  


Current Time: Tue Mar 19 08:49:26 GMT 2024

Powered by FUDForum. Page generated in 0.04132 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top