[vtk-developers] undo / redo for widgets
Dean Inglis
dean.inglis at camris.ca
Wed Nov 25 17:24:01 EST 2009
Hi Andrew,
I was thinking unlimited, at least as far as memory would allow,
but it could be capped and probably should be at some
reasonable level depending on the widget representation complexity.
maybe the API could be
> int CanUndo(){return 0;} // by default for all classes that decide not
> int CanRedo(){return 0;} // to reimplement these methods return false
> void UpdateHistory(){} // or some other name and by default do nothing
void SetMaximumHistorySize()
> void Undo(){}
> void Redo(){}
Dean
>I must have missed the start of this thread.
>What levels of undo/redo do you envisage having? Or will it be limited
>to a single undo/redo?
>Regards
> Andrew
On Thu, Nov 26, 2009 at 6:54 AM, Dean Inglis <dean.inglis at camris.ca> wrote:
> Will,
>
> absolutely, just ran out of steam momentarily... ;)
>
> My impression is that vtkWidgetRepresentation could have
> the optional methods:
>
> int CanUndo(){return 0;} // by default for all classes that decide not
> int CanRedo(){return 0;} // to reimplement these methods return false
> void TakeSnapShot(){} // or some other name and by default do nothing
> void Undo(){}
> void Redo(){}
>
> Implementation would then be representation dependent.
>
> Dean
>
> -----Original Message-----
> From: Will Schroeder [mailto:will.schroeder at kitware.com]
> Sent: November-25-09 2:37 PM
> To: dean.inglis at camris.ca
> Cc: VTK Developers
> Subject: Re: undo / redo for widgets
>
> Dean-
>
> Well I can imagine any widget benefiting, for example slider widget,
> you may want to undo a value change; affine or box widget; reset a
> transformation, etc.
>
> Am I answering your question? Doe this make sense?
>
> Will
>
> On Wed, Nov 25, 2009 at 2:32 PM, Dean Inglis <dean.inglis at camris.ca>
wrote:
>> Hi Will,
>>
>> I'm breaking this off into a separate thread. What other (VTK) widgets
>> and/or instances would it be desirable to have undo redo?
>>
>> Dean
>>
>>
>>>I'm rethinking my answer on this one, I retract my previous statement
>>>:-) I know there is some support for this in the paintbrush widgets; I
>>>guess my premature reaction is more of a question: can we step back
>>>and think about redo/undo at a higher level across all widgets?
>>
>>>Will
>>
>> On Wed, Nov 25, 2009 at 1:46 PM, Will Schroeder
>> <will.schroeder at kitware.com> wrote:
>>> IMHO Undo/redo is an application level feature. I do not think it
>>> belongs in individual classes.
>>>
>>> If you want to raise a discussion about general approaches for
>>> undo/redo that is a different matter.
>>>
>>> Will
>>>
>>> On Wed, Nov 25, 2009 at 1:33 PM, Dean Inglis <dean.inglis at sympatico.ca>
>> wrote:
>>>> Hi all,
>>>>
>>>> I would like to add undo redo capability for vtkContourWidget. The
>>>> implementation would be to have vtkContourRepresentation's internals
>>>> modified as follows:
>>>> 1) add Copy methods to the vtkContourRepresentationNode:
>>>>
>>>> void Copy( vtkContourRepresentationNode* node )
>>>> {
>>>> vtkstd::vector< vtkContourRepresentationPoint* > points =
>> node->Points;
>>>> vtkstd::vector< vtkContourRepresentationPoint* >::iterator it1, it2;
>>>>
>>>> memcpy( this->WorldPosition, node->WorldPosition, 3 * sizeof( double
> )
>>>> );
>>>> memcpy( this->WorldOrientation, node->WorldOrientation, 9 * sizeof(
>>>> double ) );
>>>> memcpy( this->NormalizedDisplayPosition,
>>>> node->NormalizedDisplayPosition, 2 * sizeof( double ) );
>>>> this->Selected = node->Seleced;
>>>>
>>>> this->Points.resize( points.size() );
>>>> for( it1 = points.begin(), it2 = this->Points.begin();
>>>> it1 != points.end() && it2 != this->Points.end();
>>>> it1++, it2++ )
>>>> {
>>>> ( *it2 ) = new vtkContourRepresentationPoint;
>>>> memcpy( ( *it2 )->WorldPosition, ( *it1 )->WorldPosition,
>>>> 3 * sizeof( double ) );
>>>> memcpy( ( *it2 )->NormalizedDisplayPosition, ( *it1
>>>> )->NormalizedDisplayPosition,
>>>> 2 * sizeof( double ) );
>>>> }
>>>> }
>>>>
>>>> and the vtkContourRepresentationInternals:
>>>>
>>>> void Copy( vtkContourRepresentationInternals* internal )
>>>> {
>>>> vtkstd::vector< vtkContourRepresentationNode* > nodes =
>> internal->Nodes;
>>>> vtkstd::vector< vtkContourRepresentationNode* >::iterator it1, it2;
>>>>
>>>> this->Nodes.resize( nodes.size() );
>>>> for( it1 = nodes.begin(), it2 = this->Nodes.begin();
>>>> it1 != nodes.end() && it2 != this->Nodes.end();
>>>> it1++, it2++ )
>>>> {
>>>> ( *it2 ) = new vtkContourRepresentationNode;
>>>> ( *it2 )->Copy( *it1 );
>>>> }
>>>> }
>>>>
>>>> and implement the following:
>>>>
>>>> // Description:
>>>> // Records the current layout of nodes adding them to the node history
>>>> list
>>>> // so that they can be undone/redone.
>>>> virtual void TakeSnapshot();
>>>>
>>>> // Description:
>>>> // A history of changes to the layout of nodes is kept internally and
>>>> // externally by calling TakeSnapshot().
>>>> // These two methods are used to go back to earlier changes to the
>> contour
>>>> // or return to more recent ones.
>>>> virtual void Undo();
>>>> virtual void Redo();
>>>>
>>>> // Description:
>>>> // Methods to determine whether there is any history left to undo or
>> redo.
>>>> virtual int CanUndo();
>>>> virtual int CanRedo();
>>>>
>>>> by maintaining protected members:
>>>>
>>>> //BTX
>>>> vtkstd::vector< vtkContourRepresentationInternals* >
>>>> InternalHistory;
>>>> vtkstd::vector< vtkContourRepresentationInternals* >::iterator
>>>> InternalHistoryIterator;
>>>> //ETX
>>>>
>>>> Also, can the SelectedNodesCursorShape be exposed through the public
API
>>>> of vtkOrientedGlyphContourRepresentation as is done for SetCursorShape
>> and
>>>> SetActiveCursorShape ?
>>>>
>>>> Dean
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> William J. Schroeder, PhD
>>> Kitware, Inc.
>>> 28 Corporate Drive
>>> Clifton Park, NY 12065
>>> will.schroeder at kitware.com
>>> http://www.kitware.com
>>> (518) 881-4902
>>>
>>
>>
>>
>> --
>> William J. Schroeder, PhD
>> Kitware, Inc.
>> 28 Corporate Drive
>> Clifton Park, NY 12065
>> will.schroeder at kitware.com
>> http://www.kitware.com
>> (518) 881-4902
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>
>
>
> --
> William J. Schroeder, PhD
> Kitware, Inc.
> 28 Corporate Drive
> Clifton Park, NY 12065
> will.schroeder at kitware.com
> http://www.kitware.com
> (518) 881-4902
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
--
___________________________________________
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney 2006 NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___________________________________________
More information about the vtk-developers
mailing list