Hi,
To Ingmar:
thanks for the tip! I can avoid the MITK core modifications at least for
hiding the nodes.
The layer problem is however still there.
To all:
I am wondering why does the layer property have such a strong influence
on creating the parent-child relationships.
Isn't the information about the parent-child relationship in conjunction
with a simple topological sort enough?
I feel it would be better to take the UID-based information to create a
graph, then make a topo-sort on it and only then perhaps to use the
layer property to sort the sibling items?
Would such a contribution to SceneReaderV1 be welcome?
Rostislav.
On 01/04/2014 20:01, Wegner wrote:
> Hi Rostislav,
> did you see, that you also can use nodes without a dedicated BaseData
> (empty node) to hide child-nodes?
> There is an option in the Workbench preferences (section DataManager)
> where you can toggle visibility of these nodes. Default behavior is (i
> think) that empty nodes are not shown in the DataManager. All
> child-nodes are also invisible. For debug purposes you could activate
> the preference and for regular users you can deactivate it again.
> Maybe that solves one of your problems.
> ;) Ingmnar
>
>
>
> Am 01.04.2014 19:52, schrieb Rostislav Khlebnikov:
>> Hi guys,
>>
>> it seems to me that there is no way to save the objects marked as
>> "helper object" when the scene is being saved (it is kinda hard-coded in
>> the scene writer). While I feel that this is absolutely justified (these
>> are "helper objects" after all), I would like to have some nodes hidden
>> from the user, but which would be saved with a project. My use case is:
>> I have the PlanarFigure data node which represents a segmentation of a
>> vessel path cross section. It could be a simple circle created manually,
>> but it can also be a result of smoothing the boundary of a 2D
>> segmentation. The segmentation is performed on a small (say, 50x50mm)
>> slice extracted from a reference image and I want to save this slice
>> along with the segmented slice image to the scene. On the other hand I
>> don't want to clutter the Data Manager with these nodes. After looking
>> at the QmitkDataStorageTreeModel and QmitkExtFileSaveProjectAction it
>> seems to me that this behavior is impossible without modifications to
>> the MITK code.
>>
>> What do you think would be a good approach to this problem? For now I
>> have modified the QmitkDataStorageTreeModel to not show the nodes marked
>> as ("hidden object" || "helper object"). It works fine except that the
>> layers are not adjusted for helper objects and I have to set them
>> manually for the scene to load correctly. Overall, I feel that this is
>> quite a dirty hack and I would like to hear your opinion on this.
>>
>> There is still one more problem, however. As the nodes are not visible
>> in the Data Manager, they cannot be directly deleted when the parent
>> node is. I can obviously handle this in my view which creates these
>> objects, but what if the view is closed? It would be nice if I could
>> mark a node as "Requires hierarchical deletion", which would be
>> processed by the data storage. What would be the best approach to this?
>> Perhaps having a data storage listener which would be registered when my
>> plugin is loaded? Or having my own datastorage subclass which would be
>> set as the active data storage? Or do you think this might be useful for
>> a wider range of applications and could be implemented in the
>> StandaloneDataStorage? Perhaps, a ContourModelSet might be just a node
>> with metainformation about its hidden children - then the separate
>> mappers, interactors and IO classes /for the set /wouldn't be necessary
>> anymore and it might rely on the ContourModel subclasses for that. I
>> feel that this is a topic for a separate discussion though and I will
>> write another e-mail about that as it is unclear how to implement some
>> of the necessary functionalities, but I do believe this is a more
>> flexible approach.
>>
>> One unrelated thing is the incremental scene saving. What I mean by that
>> is while a user works on a project it would be nice to save the progress
>> from time to time. However, the fact that saving an image takes a very
>> significant amount of time and that it is being repacked evey time the
>> scene is saved, I'm afraid that the users will be discouraged to do so.
>> So it would be nice to speed up the saving process - perhaps by
>> detecting that the image hasn't changed and it doesn't need to be
>> repacked or by having the save process in a separate thread. I'm pretty
>> sure such things already came up and perhaps there is already some
>> solution to this.
>>
>> Thank you,
>> Rostislav.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> mitk-users mailing list
>> mitk-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mitk-users
>>
> ------------------------------------------------------------------------------
> _______________________________________________
> mitk-users mailing list
> mitk-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
