<div dir="ltr">+1</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 23, 2015 at 6:12 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Mar 23, 2015 at 2:51 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
> Hi David,<br>
><br>
> It's apparent to me that part of the difficulty surrounding this change is<br>
> due to the name of the method.  Why not use a new name?<br>
><br>
> bool ComputeBoundsForViewport(vtkViewport *, double bounds[6]);<br>
><br>
> I confess that I have an ulterior motive.  I like all Get() or Set() methods<br>
> to get/set a property that depends only on the the object itself.  Here,<br>
> the Bounds depend on both the object and on a second object.  So I<br>
> don't consider this method to be a "getter" in the strict sense, hence<br>
> "ComputeBounds" rather than "GetBounds".<br>
><br>
> Basically, I like it when Get methods are associated with properties/traits<br>
> of the object.  Eventually, VTK's wrappers might associate Set/Get<br>
> methods with Python properties.  In fact, this idea can already be seen<br>
> in action in tvtk, Enthought's Traited VTK.<br>
><br>
>  - David<br>
><br>
><br>
> On Mon, Mar 23, 2015 at 9:18 AM, David Lonie <<a href="mailto:david.lonie@kitware.com">david.lonie@kitware.com</a>><br>
> wrote:<br>
>><br>
>> On Fri, Mar 20, 2015 at 9:42 AM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Fri, Mar 20, 2015 at 7:17 AM, David Lonie <<a href="mailto:david.lonie@kitware.com">david.lonie@kitware.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie <<a href="mailto:david.lonie@kitware.com">david.lonie@kitware.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>> 2) If so, how can I teach the wrappers about it?<br>
>>>>><br>
>>>>><br>
>>>>> Adding things like this to Tcl is easier than for Java or Python, but<br>
>>>>> it's more than an afternoon's work.<br>
>>>><br>
>>>><br>
>>>> One more thing:<br>
>>>><br>
>>>> If you know offhand, can you briefly outline the steps that are needed<br>
>>>> to do this? That might help clarify whether the maintenance burden is<br>
>>>> excessive or not. Would it be a one-time deal that would teach Tcl how to<br>
>>>> wrap all similar methods, or would it need to be repeated for every similar<br>
>>>> method that gets added?<br>
>>><br>
>>><br>
>>> My brief outline is this: find the code in vtkWrapTcl.c that builds<br>
>>> arrays to be used as return values, and then do something similar for this<br>
>>> new kind of method signature, except have it assign a global name (whatever<br>
>>> name was passed as a parameter) to the new array instead of returning it.<br>
>>> If it is done for this method, it should work for all similar methods.<br>
>><br>
>><br>
>> This seems more doable than I'd feared, since it'd be a generic approach<br>
>> that should "just work" for similar cases.<br>
>><br>
>> It sounds like there's a lot of support for removing Tcl, but it's<br>
>> unlikely that we'll see it go away completely anytime soon for a multitude<br>
>> of reasons. So back to the immediate issue of how the GetBounds change can<br>
>> be made to work with the wrappers, I see three options:<br>
>><br>
>> 1) Train the wrappers to understand it. Might not be worth the effort if<br>
>> we're planning to pull support soon.<br>
>><br>
>> 2) Add an additional non-deprecated GetBounds signature<br>
>><br>
>> double* GetBounds(vtkViewport*)<br>
>><br>
>> I don't like this approach as it has issues thread safety, and requires<br>
>> each object to carry around an array just to pass results back to a caller<br>
>> -- a pattern we should be moving away from. I'd be more supportive of this<br>
>> approach if we decided to use vtkTuple<double, 6> instead of double*, but<br>
>> this would also be likely to require some significant wrapper training<br>
>> and/or concrete vtkTuple subclasses.<br>
>><br>
>> 3) Begin a long-term deprecation of Tcl. We'll not plan on removing it<br>
>> completely anytime soon, but enabling Tcl wrapping will also require<br>
>> enabling legacy code in VTK. This way the old legacy GetBounds, etc<br>
>> signatures will still be available to Tcl, and feedback from the deprecation<br>
>> would help us understand the full impact of completely removing Tcl, as<br>
>> we'll grab the attention of users that might not follow the mailing lists.<br>
>><br>
>> My vote is for 3 -- it's an easy change that gives people a heads-up about<br>
>> then inevitable future removal of Tcl support, and ensures that everything<br>
>> will "just work" for legacy code until we decide to completely pull the<br>
>> plug.<br>
>><br>
>> Thoughts? Votes? Alternatives?<br>
>><br>
>> Dave<br>
><br>
><br>
><br>
</div></div><span class="im HOEnZb">> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
><br>
><br>
<br>
<br>
<br>
</span><span class="im HOEnZb">--<br>
Unpaid intern in BillsBasement at noware dot com<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br></div>