Secondary question - we already have a mechanism to make cells not editable: that presumably doesn't handle your immediate need?

Thanks for having a look!

This really belongs in the display layer, but we didn't get that implemented. At it's core you should be able to have two views of the same underlying data with different enabled/selected behaviour.

So in the current design, where it belongs is in theValueType.

Sure, I hesitated to do put this inValueType.. I did it inDataModel for a bad reason: it allows you to set the behaviour once for all indexes, while in case of a table with multipleValueTypes, you would have to implementis_enabled for each of them if you want, for instance, to disable a full row or column. Reading you, I get that this should be the role of thedisplay layer you mentioned, whileDataModels would simply take care of shaping/accessing the data, is that right ?

Also, needs tests!

Ahah sure! I forgot to make this PR a draft, it is done now.

Secondary question - we already have a mechanism to make cells not editable: that presumably doesn't handle your immediate need?

For my use case, I want a visual feedback and having the item non selectable. The idea is to show to the user that the item istemporarily disabled, following an action she/he did on it that typically takes a few seconds.

I would not be opposed to having the value type grow attributes for being editable and selectable, with the understanding that that might change in the future. The behaviour and code should likely look an awful lot like the code for handling editability.

@corranwebster I am good with moving that code toValueType, although if it is very likely to change or to conflict with existing aspirations in this repo, then I think it is better to close this PR: I can just implement a small patch where I need it. What do you think ?