[Paraview] Can a collaborative client share a pipeline without creating a view itself?

[Peter Debuchev]

Dear Utkarsh,
thank you for these explanations. If you feel like I "keep asking time
consuming questions over and over again without contributing back to the
community much", it is, because I'll need a long time to get to a point
where I can help others. Maybe never. Depends on the help I get :(

If you find some time to look back into this, please drop me a message.
I'll appreciate. I'll continue developing a minimal solution with only VTK
dependencies in the meantime.

Peter


2016-07-14 14:29 GMT+02:00 Utkarsh Ayachit <utkarsh.ayachit at kitware.com>:

> > If collaboration is experimental in ParaView, I'd say so in the very
> beginning of any article documenting or blogging about those functions.
> Still, in an experimental feature, there should be suffiecient interest to
> fix bugs, or "unsupported" would be a better term.
>
> Makes sense. Note that there's nothing new that has popped up about
> collaboration since 2012. Then, it wasn't experimental..over time due
> to lack of use and continuous iterations to avoid deteriorations now I
> would, personally, consider it experimental. Also, I vaguely remember
> saying so in the very first emails about this. Maybe I remember it
> wrong. In fact, I am
>
> > One problem I see with the (free, of course) help in this mailing list
> is that one never knows whether someone is still considering the problems
> adressed in the list after a week or so. Often I see problems half
> solved,but the remaining - hard - problem is then silently ignored. I
> assume that you communicate internally who is assigned which question,
> given that you consider them worthwile at all, so that not two people work
> on the same. Just a suggestion, could you send a short "I'll look into
> this", and, more importantly "Sorry, we can't solve this problem"? It is
> much better to know that one has to go another path than sitting and wait
> and maybe ask again and again because nobody dares to say that there is no
> solution for a problem that seemed easy in the beginning.
>
> While that makes sense, I am not sure there's anyway of enforcing
> that. No, we don't have internally communications about who's
> answering what. Mailing lists are community driven. Community extends
> beyond just Kitware. Things get dropped not because no one dares to
> say there's no solution, but firstly, because people are busy. I often
> see emails with "not supported yet", "it's a bug, please report it"
> etc. etc. And secondly, because community is a two way street. Being
> human, I would be more inclined to help someone out who's helped the
> community out before. If someone keeps asking time consuming questions
> over and over again without contributing back to the community much, I
> think one can be forgiven to prioritize responding to that question
> below others. Thirdly, mailing lists are not akin to "customer
> support" in traditional sense. There are paid services
> (http://www.kitware.com/products/consulting.html) for that.
>
> Going back to your collaboration issue, I can try to see if I can
> reproduce it in near future -- but I really can't guarantee when. Much
> to my dismay, there are way too many things on my todo list.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20160714/3b844cea/attachment.html>