Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [nattable-dev] Developer meeting

Hi Edwin, hi fellows,

Edwin Park wrote [2013-06-12 00:13]:
Fellow committers,

Dirk and I have set up a regular meeting every Thursday at 1:00pm GMT
(9:00 am in NYC, 2:00pm in London, 3:00pm in Germany) where we will be
discussing NatTable development. Please let either of us know if you'd
like to join in and we can send you the Google Hangout invite. You're
welcome to join whenever you can, however frequently or infrequently you
are available.

We'll be discussing ongoing work on NatTable 1.x at the meeting, but we
are also turning our attention to building out a next generation
architecture for NatTable. This involves several radical new concepts
including multiple renderers (we're looking at JavaFX and SWT), major
refactoring and simplification of the layer interface, CSS support,
support for arbitrarily large data sets, multiple viewports, nested
tables, etc. We have started building out some of this in the
experimental NatTable repo in git. If you'd like to see where we are
with it, please join the developer meeting!

unfortunately I could not yet participate in the meetings. Nevertheless here is some input.

It seems we had similar idea for simplifying the layer interface: make most API independent of the orientation. You called it Axis, I named it Dim: https://github.com/walware/ecommons-uimisc/blob/1086ea90635821bfe3f82383133cf880bd914de8/de.walware.ecommons.inatable.core/src/org/eclipse/nebula/widgets/nattable/layer/ILayerDim.java . This can really safe a lot of code, avoiding to write always the same stuff for columns and rows. Old implementations of layers have simple dim objects which forward the calls to the old API. Based on the new "dim" API I reimplemented for example the viewport layer and composite layer (I had to solve other issues). Of course, writing code for both orientations once is not limited to layers, the pattern can be also used for commands, events etc. The class AbstractSelectDimPositionsCommand/ViewportSelectDimPositionsCommand is an example for that in my branch.

Another major change I made is the support of large tables, see also:
http://www.walware.de/?page=/it/statet/log.html&jump=long_vectors .
I switch from 'int' to 'long' for positions, indexes and pixels. Among others, I also had to replace list and arrays with single position items by list with position ranges e.g. in the selection model/layer.

What are your plans for the next version? Will it use xtend? Please share your results of the meetings.

Regards
Stephan



Thanks,
Edwin



Back to the top