Compound Filters

Screen capture of the paraview bundle creation wizard.

Screen capture of an alternate design proposal.

This page captures discussion on creating compound filters. Mark has created a 'Bundle Wizard, which takes you through the process of creating a bundle. Also note that there's another related page on this subject: [page] which deals with the data issues involved.

Comments

The wizard is really cool. I love it! I have a few questions/todo items:

1. Mark called compound proxies bundles. Would people understand what it is? As a non-native English speaker, it is not a common word for me. I actually like it now that I am used to it.

Either name sounds fine to me, but it should be consistent. We have been using the name compound for a long time, so my vote is to keep calling them compound proxies.

--Ken

'Compound Proxies' is our internal name - I don't think we planned to call them that when we released this capability to our customers. I don't have a strong objection to 'bundles' at the moment. Let's chat about this next week.

--Hollywood 17:59, 23 Jun 2006 (EDT)

2. We have to add some label-like text to properties in SM so that people can easily understand what they mean. These could be used in auto-generated panels as well as the wizard. We also need some help text for each property in SM.

3. We have to add connections between 3D widges and proxies like Tim suggested. Otherwise, bundles won't have 3D widgets associated with them. We should do this next month.

4. Will all bundles have auto-generated panels? If custom panels are allowed, how are we going to associate them with loadable bundles.

--Berk

You can see the fabulously-complicated logic for instantiating custom panels in pqObjectInspectorWidget::setProxy() - assuming that you can identify a proxy as a compound, and can obtain something to act as an identifier (name, XML filename, etc), you could instantiate a corresponding custom panel.

--Tim

So, I can't tell if Tim's using 'fabulous' in a good way or a bad way ... :) We may not need to support custom panels - if a user is sophisticate enough to create a custom panel, doesn't that imply that they're willing to encode the bundle in C++, thereby making this a new filter? If we build the filter in C++, we build the panel too. Thus, we only need two steps: bundles with auto-generated panels, and full-on fitlers with custom panels. No middle ground

--Hollywood 18:04, 23 Jun 2006 (EDT)

Holy ka-schmoly, this is really great work - it makes the whole thing real, and it's great to see it in such a complete, professional-looking implementation. I think the use of a wizard here is really ideal - leading the user through the process in this way is very nice. After playing with this a while, it seems to me that we can use our 'edit in place' guidelines to make it a bit easier. Here's a proposal for doing it in place. Lemme know what y'all think.

One more item - this brings up a slew of 'other' stuff you'd like to edit for a 'bundle/compound filter':

• Visibility of each filter
• Exposing controls for things like the 3D widgets (for example, of a cutplane) that:
  • You'd like to edit by hand, and
  • You'd like to grab onto and drag.

Also, remember that we're headed towards a future in which we'll have 'bundles within bundles'. How does this complicate things?

--Hollywood 17:42, 23 Jun 2006 (EDT)