|
Notes |
|
|
(0006849)
|
|
Clinton Stimpson
|
|
2007-03-19 18:41
|
|
Perhaps something like an exclusion list?
So when paraview loads plugins with filters, they still go into the filters menu.
|
|
|
|
(0006850)
|
|
Ken Moreland
|
|
2007-03-19 18:55
|
|
I originally recommended having a hint the SM XML. I was told by Berk and others that that would not work well for custom applications that want to limit what filters they expose.
It occurs to me that the exclusion list may work well in the short term, but have consequences in the long term for custom applications. Over time, we will be adding filters to PV. Custom appliations that only provide a small set of hand-picked filters will not want to see these either. So over time the exclusion list will become invalidated unless someone is constantly monitoring it. I also worry that plugins may want to add "internal" filters that are not exposed but will have no way to exclude them.
How about this: the SM XML allows a hint that states a particular proxy is internal and should not be exposed in any GUI. The client classes also provide an inclusion list that custom applications can use to set which filters they want. By default if no inclusion list is specified, all filters that do not have a hint to hide them are made available. Is this a pain to implement? |
|
|
|
(0006915)
|
|
Utkarsh Ayachit
|
|
2007-03-22 18:08
|
|
|
I think Berk is working on this. |
|
|
|
(0006943)
|
|
Berk Geveci
|
|
2007-03-27 09:48
|
|
|
The list of filters is now controlled by xml files. After the branch, we should also move internal filters from "filters" group to "internal_filters" group. |
|