Re: [Paraview] Better names for 'representations' ?
Hey Guys, That sounds fine. I'll be happy as long as there is a slightly easier / more transparent way of identifying the representation once you know the view and source. Thanks, -Eric On Mar 12, 2009, at 12:48 PM, Berk Geveci wrote: I agree with Utkarsh. Since the user interface hides the representation objects from the user, the appropriate interface for getting representations should take (view, source) as the argument. Views on the other hand should probably be named so that it is easy to match Python names to something in the GUI. -berk On Thu, Mar 12, 2009 at 9:22 AM, Utkarsh Ayachit utkarsh.ayac...@kitware.com wrote: Eric, The request does seem reasonable. However, with the upcoming changes to the python API, it will provide better/nicer ways of locating representations irrespective of their names. So the naming issue would probably be redundant. Utkarsh On Wed, Mar 11, 2009 at 3:12 PM, Eric E. Monson emon...@cs.duke.edu wrote: Hello, I am wondering whether it would be possible or reasonable to have ParaView match the names of proxies in 'sources' and 'representations'? When working from Python, it's easy to get a proxy from 'sources' if you know its name from the pipeline. The name even changes when you edit it in the pipeline. In contrast, 'representations' proxies are named 'DataRepresentation1', 'DataRepresentation2', etc., and to find the proper proxy I always have iterate through the representation proxies and check for a match between the proxy from 'sources' and the representation proxy Input. Since I don't understand much about all the client/server/proxy stuff, I don't know if this is a reasonable request, or if it's difficult for PV to do things internally like change the representation name when the source name is changed. Thanks, -Eric -- Eric E Monson Duke Visualization Technology Group ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Better names for 'representations' ?
Eric, The request does seem reasonable. However, with the upcoming changes to the python API, it will provide better/nicer ways of locating representations irrespective of their names. So the naming issue would probably be redundant. Utkarsh On Wed, Mar 11, 2009 at 3:12 PM, Eric E. Monson emon...@cs.duke.edu wrote: Hello, I am wondering whether it would be possible or reasonable to have ParaView match the names of proxies in 'sources' and 'representations'? When working from Python, it's easy to get a proxy from 'sources' if you know its name from the pipeline. The name even changes when you edit it in the pipeline. In contrast, 'representations' proxies are named 'DataRepresentation1', 'DataRepresentation2', etc., and to find the proper proxy I always have iterate through the representation proxies and check for a match between the proxy from 'sources' and the representation proxy Input. Since I don't understand much about all the client/server/proxy stuff, I don't know if this is a reasonable request, or if it's difficult for PV to do things internally like change the representation name when the source name is changed. Thanks, -Eric -- Eric E Monson Duke Visualization Technology Group ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Better names for 'representations' ?
I agree with Utkarsh. Since the user interface hides the representation objects from the user, the appropriate interface for getting representations should take (view, source) as the argument. Views on the other hand should probably be named so that it is easy to match Python names to something in the GUI. -berk On Thu, Mar 12, 2009 at 9:22 AM, Utkarsh Ayachit utkarsh.ayac...@kitware.com wrote: Eric, The request does seem reasonable. However, with the upcoming changes to the python API, it will provide better/nicer ways of locating representations irrespective of their names. So the naming issue would probably be redundant. Utkarsh On Wed, Mar 11, 2009 at 3:12 PM, Eric E. Monson emon...@cs.duke.edu wrote: Hello, I am wondering whether it would be possible or reasonable to have ParaView match the names of proxies in 'sources' and 'representations'? When working from Python, it's easy to get a proxy from 'sources' if you know its name from the pipeline. The name even changes when you edit it in the pipeline. In contrast, 'representations' proxies are named 'DataRepresentation1', 'DataRepresentation2', etc., and to find the proper proxy I always have iterate through the representation proxies and check for a match between the proxy from 'sources' and the representation proxy Input. Since I don't understand much about all the client/server/proxy stuff, I don't know if this is a reasonable request, or if it's difficult for PV to do things internally like change the representation name when the source name is changed. Thanks, -Eric -- Eric E Monson Duke Visualization Technology Group ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Better names for 'representations' ?
Hello, I am wondering whether it would be possible or reasonable to have ParaView match the names of proxies in 'sources' and 'representations'? When working from Python, it's easy to get a proxy from 'sources' if you know its name from the pipeline. The name even changes when you edit it in the pipeline. In contrast, 'representations' proxies are named 'DataRepresentation1', 'DataRepresentation2', etc., and to find the proper proxy I always have iterate through the representation proxies and check for a match between the proxy from 'sources' and the representation proxy Input. Since I don't understand much about all the client/server/proxy stuff, I don't know if this is a reasonable request, or if it's difficult for PV to do things internally like change the representation name when the source name is changed. Thanks, -Eric -- Eric E Monson Duke Visualization Technology Group ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
