Hello Sascha,
I like the approach that you proposed. I will give it a shot and get
back at you either will pull request or more questions :)
Also, I have quite a specific use case which was the reason why I
started the whole "picking" thing. I need to pick some specific "faces"
of my objects.
So this will also let me test the flexibility of node picking approach I
will implement - this node picking will have to be overriden by other
observers in some cases.
All best,
Rostislav.
On 29/08/2014 17:31, Sascha Zelzer wrote:
Hi Rostislav,
DataNode selections based on picking in render windows is one of my favourite
missing
feature requests (the bug entry is really old). Great to see that you started
working on it!
I will first comment on the interaction issues and then on the selection
provider approach.
Picking interaction
-------------------
I discussed the issue with Christian and we think that the DisplayInteractor is
probably
not the best candidate to implement this. If you think your approach is worth
pursuing,
please publish a branch so we can discuss the code changes. But read on first
;-)
The FilterEvents() method was designed to pre-select events for which the
state-machine
should be notified at all. And the cause for ignoring the actions return values
is that
they are a legacy mechanism to decide if a state change should take place, but
that
mechanism was superseded by the introduction of "conditions".
The "picking process" (initiated by a mouse click, shift+click or similar)
looks like a
good candidate for being implemented as another mitk::InteractionEventObserver
class,
independent of the DisplayInteractor and without any state-machine logic. By
reacting
to mouse press and release events in the Notify() method, you could check if
there was
no drag between the two and then do the picking. This would work in parallel
with the
existing DisplayInteractor, so e.g. rotations in the 3d view should still take
place
(without picking because there was a drag).
I would propose the following architecture:
1. Create a mitk::PickingEventObserver sub-class of
mitk::InteractionEventObserver
in Core/Code/Interactions. For notification of picked data-nodes, use a
public member
of type mitk::Message<mitk::DataNode*> (similar to the mitk::DataStorage
class).
2. In org.mitk.core.services, register an instance of mitk::PickingEventObserver using
the us::ModuleContext class. Make sure the observer instance is initially
disabled.
Also use a service property named "name" with a value like "DataNodePicker"
when
registering the service.
3. To enable/disable picking in the application, we thought about adding a menu
entry
and/or toolbar button which retrieves the highest ranked
InteractionEventObserver
with (name=DataNodePicker) and calls Enable()/Disable() on it,
respectively. That
way, picking should work in all render windows.
DataNode selection provider
---------------------------
I would essentially go the route you already proposed. But instead of adding the
selection provider to the QmitkStdMultiWidgetEditor, we could add it to
QmitkAbstractRenderEditor such that it works for other displays as well. Again
an
initial draft how it could work:
1. Create a mitk::PickedDataNodeSelectionProvider in org.mitk.gui.common/src
which
inherits from berry::ISelectionProvider and returns a
mitk::DataNodeSelection
in its implementation of the GetSelection() method. To establish a
connection
with the picking process, the selection provider class should internally
track
the highest ranked mitk::InteractionEventObserver with (name=DataNodePicker)
and connect to its data-node messages after a dynamic_cast.
2. Add a new private "virtual berry::ISelectionProvider::Pointer
GetSelectionProvider() const"
method in QmitkAbstractRenderEditor which is called in the Init() method to
register the selection provider. The default implementation uses the new
mitk::PickedDataNodeSelectionProvider class.
Of course I am not sure if all this works out or if there are some unconsidered
issues. Any feedback to this proposal is welcome. We can also try to
organize/split
the work depending on your resources and willingness to tackle this. I think
this
could be an awesome new feature for any MITK based application.
Thanks,
Sascha
On 08/28/2014 07:56 PM, Rostislav Khlebnikov wrote:
Hi guys,
I made some changes to my MITK fork and I wonder if you might be
interested. Basically, I modified DisplayInteractor to support simple
clicks, as well as ctrl and shift clicks that find the picked node
using the basic picking interface. This can be enabled/disabled by
using the MouseModeSwitcher with a new "Picking" mouse mode.
The only thing that needs to be changed is access to some selection
provider which would inform all the views about selection change. I
would need some help regarding how to make this properly. Should
DisplayInteractor expose some picking events and the
QstdMultiWidgetEditor would listen to? Then this editor should be a
selection provider itself. Is this the way to go?
Please answer some time soon.
Rostislav.
On 25/08/2014 22:09, Rostislav Khlebnikov wrote:
Just tried a simple implementation of this approach and it works
perfectly.
Would you agree with this change? Should I make a /yet another/ pull
request? :)
Rostislav.
On 25/08/2014 22:03, Rostislav Khlebnikov wrote:
Hi guys,
I'm implementing the interactor to select some specific sub-objects but
I have a problem making it work with the display interactor.
Basically, I want the following quite natural behavior in 3D window:
- if a user clicks on the object of interest - it should be selected
- if a user clicks and drags - the view should rotate without
triggering the selection
Basically, I have a DataInteractor that processes mouse release events
in the state machine. What I do within it is the following:
Within FilterEvents method:
- On mouse press event, I record that dragging might have started and
return mitk::DataInteractor::FilterEvents, which as far as I understand
leads to returning true if there are any transitions for this event . In
this case, I have no transitions for that event, so it is being passed
to the vtk interactor style, which starts rotation.
- On mouse move event, I record that dragging actually started, with
the same return value as above.
- On mouse release event, I check if there was any actual dragging.
And if yes, I ignore the event by returning false so it would be passed
to the vtk interactor style to stop the rotation. But if not - there is
a transition and the event is accepted.
The problem is that the vtk interactor style does not get the mouse
release event in case a simple click was performed. Therefore it
continues rotating even though no actual dragging is performed.
What are your thoughts on how this can be fixed? What I see is that the
action's return value is not used at all (see
mitk::EventStateMachine::HandleEvent). Perhaps it could mean if the
event should be passed through, similar to FilterEvents?
Rostislav.
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
