Personally I'm not a big fan of auto-converting data by default. In a branded app or in with some option turned on I think it would be great, but in paraview proper, unless we can do it with little or no memory growth or accuracy loss, I think we should stick to accuracy as much as possible. <br>
<br>We I was saying was that we need to do a much better job of helping the user figure out what they need to do, and how to do that without blowing up memory on big data.<br><br>My original point is that in paraview, and VTK itself, there is no way of knowing exactly what any given filter is going to do to the data structure beforehand unless you take a hard look at the code. You can't even tell that just by looking at the doxygen. ParaView adds extra constraints which make it even less obvious why a given filter can't be applied.<br>
<br>On a related note, can we have links to the online paraview and vtk doxygen in the in-tool help for each sourceproxy? <br><br clear="all">David E DeMarle<br>Kitware, Inc.<br>R&D Engineer<br>28 Corporate Drive<br>
Clifton Park, NY 12065-8662<br>
Phone: 518-371-3971 x109<br>
<br><br><div class="gmail_quote">On Thu, Mar 4, 2010 at 11:15 AM, Jeff Baumes <span dir="ltr"><<a href="mailto:jeff.baumes@kitware.com">jeff.baumes@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Along with Dave's comment, I think auto-converting would be good to<br>
help with this. For example, if you want to warp an image, can't you<br>
just implicitly convert it to geometry? The result is that many things<br>
would not be greyed out anymore.<br>
<br>
It seems that would help with the cognitive load, so people don't even<br>
need to know what all the different vtkDataObject subclasses are and<br>
how to convert between them manually.<br>
<br>
That said, making icons for the different data types in the pipeline<br>
browser would probably help too, instead of everything just being a<br>
green cube.<br>
<br>
Jeff<br>
<div><div></div><div class="h5"><br>
On Thu, Mar 4, 2010 at 9:41 AM, David E DeMarle<br>
<<a href="mailto:dave.demarle@kitware.com">dave.demarle@kitware.com</a>> wrote:<br>
> One thing that new users don't like is that it is hard to find out<br>
> what filters do really and more frustratingly, why they are greyed out<br>
> once you know what one you want.<br>
><br>
> We should do a better job of documenting the input and output types of<br>
> each reader/source/filter/writer, what specifically it does, and what<br>
> the input restrictions (domains) are. Perhaps we can automate the<br>
> collection of that from the class hierarchy, doxygen, and the xml and<br>
> expose it in some intuitive manner in the UI. For example using icons<br>
> to represent input data set types and presence of cell/point scalars<br>
> etc.<br>
><br>
> I will try to put up some mockup on the wiki page shortly.<br>
><br>
> David E DeMarle<br>
> Kitware, Inc.<br>
> R&D Engineer<br>
> 28 Corporate Drive<br>
> Clifton Park, NY 12065-8662<br>
> Phone: 518-371-3971 x109<br>
><br>
><br>
><br>
> On Sat, Feb 27, 2010 at 11:45 AM, Moreland, Kenneth <<a href="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a>> wrote:<br>
>> There is lots of good stuff here. I added a bunch of megalomaniacal<br>
>> comments.<br>
>><br>
>> -Ken<br>
>><br>
>><br>
>> On 2/26/10 10:27 AM, "Utkarsh Ayachit" <<a href="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>> wrote:<br>
>><br>
>> Folks,<br>
>><br>
>> Following a discussion with Berk, I've started consolidating the ideas<br>
>> for the improvements on a Wiki page.<br>
>> Please start contributing your suggestions.<br>
>><br>
>> <a href="http://www.paraview.org/ParaView3/index.php/ParaView_Usability_Improvements" target="_blank">http://www.paraview.org/ParaView3/index.php/ParaView_Usability_Improvements</a><br>
>><br>
>> Utkarsh<br>
>> _______________________________________________<br>
>> Paraview-developers mailing list<br>
>> <a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
>> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
>><br>
>><br>
>><br>
>><br>
>> **** Kenneth Moreland<br>
>> *** Sandia National Laboratories<br>
>> ***********<br>
>> *** *** *** email: <a href="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a><br>
>> ** *** ** phone: (505) 844-8919<br>
>> *** web: <a href="http://www.cs.unm.edu/%7Ekmorel" target="_blank">http://www.cs.unm.edu/~kmorel</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Paraview-developers mailing list<br>
>> <a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
>> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
>><br>
>><br>
> _______________________________________________<br>
> Paraview-developers mailing list<br>
> <a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Jeff Baumes, Ph.D.<br>
R&D Engineer, Kitware Inc.<br>
(518) 881-4932<br>
<a href="mailto:jeff.baumes@kitware.com">jeff.baumes@kitware.com</a><br>
</font></blockquote></div><br>