qMRMLTableView is publicly inherits from QTableView, so you have access to the full Qt API, can get notifications about selection change, recolor items, etc.
While getting any information is always safe, changing information in the table at Qt level can cause inconsistency between MRML and the Qt widget. If you only make modifications that the qMRMLTableView does not care about (e.g., change of background colors) then there should be no harmful interference.
If it turns out that there are some commonly needed features that are not easy to implement (or not practical to maintain) in external code then we can add that to the qMRMLTableView.
- Cell clicked (selection change): it is easy to connect to signals of the selection model from outside code, so there should not be a pressing need to add this to the qMRMLTableView API. However, if you think that it is too complicated then we can expose simplified signals in qMRMLTableView.
- Custom formatting (background color, font, etc.) for an entire column would be relatively easy to implement in tables, because we can already store arbitrary per-column metadata, but I’m not sure how commonly needed feature is this.
- Conditional formatting: It should not be too hard to implement this in external code (when the table node is modified then run through the cells and adjust item properties in the table view). A narrow version of this could be added into a display node, where colormaps could map cell values to font or cell background colors (and maybe other lookup tables could be added for setting font size, etc.). This would probably take 1-2 weeks to implement.
You can add any of these ideas as feature requests and see how many votes they collect and we’ll prioritize them accordingly.