[Ctk-developers] Another ctkWorkflow thingie: goToStep(..) goes always back to starting step

Fri Jun 3 20:16:19 UTC 2011

Hi Daniel,

* A workflow is set of transitions.

* If you want to go from a Step X to a Step Y, a transition is required to
exists

* For conditional workflow, there is the concept of branch.

* Each time you click on finish, the pipeline (or workflow) is executed.
Upon success, it returns to the step from where the transition to the
"finish" step was done.  Having a different behavior would make sens. I
propose the following:
   * Add a property named "GoBackToOriginStepUponSuccess" to workflow.
(also open to suggestion regarding the name)
   * By default, this property would be False

Would be great if you could implement the described behavior. To do so:
   1) fork CTK on github
   2) Create a topic branch named
"add-GoBackToOriginStepUponSuccess-workflow-feature" of master
   3) Commit both feature and updated test
   4) Check that test run locally
   5) Send an email to the list asking for review with a pointer to your
topic
   6) Danielle or myself will review your topic and integrate it into master

Note: Make also sure the property is exposed in python. You could play with
the following example to make sure everything is working as expected. See
https://github.com/jcfr/SlicerPy/blob/master/slicer-visual-workflow-example.py

Thanks
Jc

On Fri, Jun 3, 2011 at 3:52 PM, Danielle Pace <danielle.pace at kitware.com>wrote:

> Hi Daniel,
>
> CanGoToStep checks to see if a path exists between two steps - so it is not
> helpful in your case.
>
> Right now, there is no method to go to a specific step without
> transitioning back.  We could add a property that dictates whether to go
> back to the starting step after successfully getting to a 'finish' step...
>
> Thanks,
>
> Danielle
>
>
>
>
>
> On Fri, Jun 3, 2011 at 3:45 PM, Daniel Haehn <haehn at bwh.harvard.edu>wrote:
>
>> Hi Danielle,
>>
>> hm this does not make totally sense to me. What about the canGoToStep
>> method - this only checks for next step?
>>
>> Wouldn't it make more sense to have the behavior I observed and you
>> described for the canGoToStep call and do not go back when you call
>> goToStep?
>>
>> Or is there another method I could use to go from step 1 to step 4, f.e.?
>>
>> Thanks
>> Daniel
>>
>> On Fri, Jun 3, 2011 at 3:40 PM, Danielle Pace <danielle.pace at kitware.com>
>> wrote:
>> > Hi Daniel,
>> > This is the intended behavior when using 'goToStep'.
>> > The idea is that, partway through the workflow, you could execute the
>> steps
>> > until a 'finish step' was reached - using the default parameters for
>> those
>> > steps.  Then you can evaluate the results that occur with default
>> > parameters.  If you get to the 'finish' step successfully, it puts you
>> back
>> > where you started - so that you can continue to step through and alter
>> > parameters if you like.
>> > If you do not get to the 'finish' step successfully (i.e. default
>> parameters
>> > produce errors on your data or because of the parameters you set in
>> prior
>> > steps), it will stop at the error.
>> > Hope that helps,
>> >
>> > Danielle
>> >
>> >
>> >
>> >
>> > On Fri, Jun 3, 2011 at 3:34 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> wrote:
>> >>
>> >> Hi guys,
>> >>
>> >> if I use ctkWorkflow.goToStep(x), the workflow goes to the step x
>> >> along the workflow (according to onEntry, validate and onExit calls).
>> >>
>> >> But then, after reaching step x, it goes directly back to where I am
>> >> coming from - again along the workflow. This goes so fast so it seems
>> >> there is no movement at all.
>> >>
>> >> I digged a little and it seems line 1035 in ctkWorkflow.cpp is not
>> >> right? After reaching the 'finish step' (which in my understanding is
>> >> the target step), it goes back to the starting step.
>> >>
>> >>
>> >> 1019 //
>> >>
>> --------------------------------------------------------------------------
>> >> 1020 void ctkWorkflow::goToStepSucceeded()
>> >> 1021 {
>> >> 1022   Q_D(ctkWorkflow);
>> >> 1023
>> >> 1024   logger.debug("goToStepSucceeded");
>> >> 1025
>> >> 1026   // after success, go back to the step at which we begin looking
>> for
>> >> 1027   // the finish step (will exit the current step and enter the
>> >> starting step)
>> >> 1028
>> >> 1029   d->createTransitionToPreviousStartingStep(d->StartingStep,
>> >> d->CurrentStep);
>> >> 1030
>> >> 1031   d->GoToStep = 0;
>> >> 1032   d->StartingStep->setStatusText("Attempt to go to the finish
>> >> step succeeded");
>> >> 1033   d->StartingStep = 0;
>> >> 1034
>> >> 1035   this->goFromGoToStepToStartingStep();
>> >> 1036 }
>> >> 1037
>> >>
>> >> Is this correct behavior and I understand the goToStep(x) call wrong
>> >> or is this a bug?
>> >>
>> >> Cheers,
>> >> Daniel
>> >> _______________________________________________
>> >> Ctk-developers mailing list
>> >> Ctk-developers at commontk.org
>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >
>> >
>> >
>> > --
>> > Danielle Pace, M.ESc.
>> > Research and Development Engineer
>> > Kitware Inc.,
>> > North Carolina Office
>> > www.kitware.com
>> > 919-969-6990 X 319
>> >
>>
>
>
>
> --
> Danielle Pace, M.ESc.
> Research and Development Engineer
> Kitware Inc.,
> North Carolina Office
>
> www.kitware.com
> 919-969-6990 X 319
>
>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>

-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110603/d1ce92c4/attachment.htm>