Hi,
>> I wonder if the use case of “open framework” means technically forking NatTable
No, it means technically to customize a NatTable instance that much that you are still using 90% of the default, but be able to do fancy stuff by providing custom interface implementations you need in your environment. The interfaces in question for example rely on trees. We have two default implementions, one that simply hides the child rows on collapse, one that is using GlazedLists TreeList, which performs a list transformation internally. This is sufficient for most of our users and we therefore hide that implementation details where possible. But I also know at least one user that needs to implement lazy loading, as the data is loaded dynamically from a server. So a custom tree model was implemented to reflect that, but it is currently to special to become part of NatTable itself. And the NatTable API allows to provide a different interface implementation if he knows what he does.
My plans for the future architecture is to make the API easier to use for default cases by still allowing to customize almost everything if needed.
Greez,
Dirk