[SOLVED] [Suggestion] Handling of container of complex class inside GUI of SOFA

[Fabien]

Hi,

I had an idea regarding the dealing with complex Object/Data. I have no idea if feasible/interesting/viable it is, but hey, we are here to discuss. 🙂

It happened several times where I wanted to pack complex class into a vector that belongs to an object in the scene graph. However, right now, the only way to handle such object through the GUI is to define the istream/ostream operator in the complex class contained inside the vector. It results in a plain text field arranged the way the dev wants, displaying the inner parameters of the class without the standard Data information.

Here is what I was wondering; is it possible to define in SOFA a Data<Vector<Data<ComplexClass>>> in such a way that when opened in the GUI, it displays a column of buttons, one button per element in the vector, and so that when clicked, it opens/expands a new windows showing the data contained inside the element selected ?

An example would be:
class Foo { Data<> member0; Data<> member1; }
class Bar: public BaseObject { Data<Vector<Data<Foo>>> vectorOfFoo; }
Class Bar could be added into the graph and its GUI would display
— vector of Foo —
|_0_|
|_1_|
.
.
. etc…

Clicking on button 0 would open a new window allowing to display/edit the Data members contained in the 0-th element of the vector.

Regarding the implementation, I think it would be necessary to specialize the class Data. However I do not know whether the Data system of SOFA would allow a nested access to inner data. On the GUI side I cannot say much since I do not have experience in that part of SOFA
There is the system of Master-Slave component in SOFA but I think it has other goals than to allow nested access to data.

I hope it was clear enough to understand.
Cheers,
Fabien

[Olivier CARRE]

Hi Fabien,
In fact the Data class already has a widget customisation method called “setWidget” so you should not have to specialise it.

Right after the data initialisation you can call this method and give it the name of the widget you want it to use in the GUI.
The name of the widget used in the function parameter has to be the same than the one used when registering the widget designed to view / edit the corresponding data in the Sofa factory.

For instance, in the “image” plugin we have a component named ImageViewer (take a look at ImageViewer.h) owning a data named “histo” of a new type “HistogramType”. To be able to view / edit this new type with the proper GUI we call histo.setWidget("imagehistogram") in the constructor of the ImageViewer class and in another file (HistogramWidget.h/cpp) we define and register its corresponding widget (inheriting QWidget since we use Qt4) in the sofa factory like this :
helper::Creator<DataWidgetFactory, HistogramDataWidget< Histogram<unsigned char> > > DWClass_histoUC("imagehistogram",true);
Here HistogramDataWidget is a widget designed to handle Histograms correctly.
In this example, the widget inheritance hierarchy is not really straight forward regarding QWidget because we have to handle template parameters to be able to deal with all kind of histogram according to pixel depth (unsigned char, float, etc.).

Take a look at this example and do not hesitate to ask if you have any questions about it.

[Fabien]

Hi Olivier,

Thanks a lot for the detailed information. I will take a look at that for my Data and come back here if I stumble on a major obstacle.

[Fabien]

An addition regarding the topic, one can look also at the class sofa::helper::vectorData to use as its name says: a vector of Data

[Author]

Posts