Some of the mentioned ideas are already implemented in

• Modules/SemanticRelationsUI/include/QmitkPatientTableModel.h
• Modules/SemanticRelationsUI/include/QmitkPatientTableWidget.h

(see T23297)

However, we can discuss different, new approaches for retrieving and storing thumbnails.

In T24738#131399, @kalali wrote:

Some of the mentioned ideas are already implemented in

• Modules/SemanticRelationsUI/include/QmitkPatientTableModel.h
• Modules/SemanticRelationsUI/include/QmitkPatientTableWidget.h

(see T23297)

However, we can discuss different, new approaches for retrieving and storing thumbnails.

These code snippets are a good basis. I would like to encapsulate the preview generation and provide it more centrally on the long run. E.g. by extending the NodeDescriptorClasses to not only query for an Icon for a specific data node, but also to offer a function to query a preview as QImage for a given DataNode (and resolution).

I wouldn't call it code snippet 😛 but yes, I agree with the idea of providing a central access to the thumbnail generation / storage functionality.

I'm currently in the process of making the patient table view available as an inspector to add it to the node dialog. The problem is now, that the dialog creates a new inspector each time it is opened. Therefore we cannot store the preview pixmaps inside the model as is is currently done (we could, but they need to be created on each dialog popup). So what are your ideas so far to centralize the preview generation?

In T24738#133164, @kalali wrote:

So what are your ideas so far to centralize the preview generation?

My thoughts regarding that topic are noted in the initial task description.

The thumbnails should be cached (e.g. in a map keyed by the data UID) to avoid unncessary regeneration of thumbnails (or as a alternative stored as a property of the node?).

This tackels also your requrirements. The question is how costly is the generation of a thumbnails. If the creation for all needed thumbnails is not to costly we could just create and cache them in the new instance. If it is to costly saving as property in the node seems the most sensible action.

It is surely to expensive to create them with each paint event. But I wonder/think, if/that creating them when creating the instance (each as caching in the view decorator) is fast enough.

Ok I'll implement a first draft and see how it works. I already stored them inside the model but since this is only temporary (for a few seconds until the dialog is closed again) I wanted to go for your idea of extending the NodeDescriptorClasses and was wondering how we could approach this. But first let me see if storing them temporary is fast enough.

First draft is implemented in T24891.

• check selection widgets for different thumbnail extraction
• allow node predicates (currently only "images" are shown)