Hi Rotislav,
my colleagues referred me again to your mails concerning persistent helper
objects and using a proxy model for the data manager. I just went through the
conversation and at least using a proxy model for filtering out nodes makes
sense to me. Unfortunately, I don't see a pull request for that issue on
github. If you could provide your changes, I will have a look and integrate
them.
Best
Michael
Von: Rostislav Khlebnikov [mailto:rostislav.khlebni...@kcl.ac.uk]
Gesendet: Donnerstag, 17. April 2014 14:15
An: mitk-users@lists.sourceforge.net
Betreff: Re: [mitk-users] Persistent helper objects, recursive deletion, and
incremental scene saving
Hi guys,
now that the 2014.03 is released, I'm really hoping to get an answer about the
concerns that I have and the changes I propose :)
Just as an additional thing about helper objects - I noticed this commit:
https://github.com/MITK/MITK/commit/88303e6af31084206d7ba7348709144f22188486
(Fixed visibility of the contours. Reason was probably that the layer was not
set correctly) - and it seems to me that if the proxy model is used and the
nodes are added to the tree model which adjusts the layers - this problem also
wouldn't be there.
Thank you,
Rostislav.
On 03/04/2014 16:41, Rostislav Khlebnikov wrote:
And hello again,
now I have a fully functional proxy model and it works absolutely great. I
think there are other potential benefits in using proxy models - such as for
example column filtering for a "TODO" in the QmitkDataStorageTableModel. I also
feel that in some cases the tree view fully collapsed upon some node
insertion/deletion from the code (I'm not sure under which exact circumstances,
although I can track this down of course) - it is not the case anymore.
On the topic of hierarchical deletion - I noticed that there's an
"inconsistent" behavior that could be solved with hierarchical deletion
possibility - i.e. when creating a segmentation the "Position #" nodes are
created. They will be deleted if the segmentation image is deleted from the
data manager view ONLY if the segmentation view is open. If the view is closed
- they will stay hanging.
Cheers,
Rostislav.
On 03/04/2014 15:02, Rostislav Khlebnikov wrote:
Hello Stefan,
thank you for the tip. However, digging quite deep into MITK code I already
noticed this property, but this is not what I am looking for. Basically I have
many objects which I would like to be hidden in the data manager and the
problem is that their layer property is not modified. So the only way I see now
is replicating the logic of QmitkDataStorageTreeModel regarding the layer
assignment for my hidden nodes which is, in my opinion, very bad practice as it
creates a lot of unnecessary code duplication and will probably break at some
point. And if I don't do this, the scene will not be loaded correctly due to
incorrect layer assignment which influences the process of restoring
parent-child relationship.
Thanks again,
Rostislav.
On 03/04/2014 14:09, Kislinskiy, Stefan wrote:
Hi,
Sorry, I didn't read all of your mails and just noticed you had problem
regarding layer ordering. Don't know if it helps but it is worth a note: If you
want to deactivate dynamic layer assignment for certain data nodes you can add
a bool property called "fixedLayer" and set it to true. Those data nodes keep
their layer. See QmitkDataStorageTreeModel.cpp:670.
Cheers,
Stefan
Von: Rostislav Khlebnikov [mailto:rostislav.khlebni...@kcl.ac.uk]
Gesendet: Donnerstag, 3. April 2014 14:46
An: mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net>
Betreff: Re: [mitk-users] Persistent helper objects, recursive deletion, and
incremental scene saving
Hi guys,
I just tried it with the QSortFilterProxyModel and it works absolutely
perfectly (node insertions/deletions as well as context menus). The nodes that
need to be hidden are hidden, yet the layers are applied correctly and thus the
scene saves and loads smoothly.
So ping me if you feel you would like to integrate these changes (probably
after 2014.03 release) and I will create the regular bug-branch-pull_request
chain.
Rostislav.
On 03/04/2014 12:43, Rostislav Khlebnikov wrote:
An alternative approach would be to add all the nodes to the
QmitkDataStorageTreeModel and thus have the layers adjusted for all the nodes
and delegate which nodes are actually shown to a
QSortFilterProxyModel<http://qt-project.org/doc/qt-4.8/qsortfilterproxymodel.html>.
Then the loader could be left as is (although I feel it would make more sence
with the changes I described before). This would also nicely separate the core
responsibilities of a QmitkDataStorageTreeModel (DataStorage sync) from the
actual display of items which will be delegated to QSortFilterProxyModel.
Again, please tell me if these changes seem reasonable to you as I am quite
eager to implement them and have time for it in the coming days.
Rostislav.
On 03/04/2014 12:28, Rostislav Khlebnikov wrote:
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<mailto:mitk-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
