I've nested a Partition filter in a Degree filter and it doesn't filter out the Degree 0 values. It does seem to work if the minimum degree value is set to 2. The attached gexf and main script are what I'm using.
Imported from Launchpad using lp2gh.
Here's the graph I'm trying to filter
I didn't test with your graph yet but I think this bug happens because of some boundary update code. The problem appears when the range is out of the boundary. In Gephi we always show you the range you can filter (with a min and a max) so you can't set up an incorrect filter. For instance if the ma degree is 10 and the min is 3 you can't create a filter [3, 200]. If you do, the system will automatically prune 200 to the limit 10. That is what is happening here I think. The range is changed and therefore the filter doesn't work.
I fixed something in the Range class and did some tests on a random graph. Can you please pull the trunk, build the new toolkit and test?
In addition I fixed another bug so you don't have to call init() on your filters anymore. That should be done by the system, but it was throwing an exception without.
Moreover, you can now execute a layout with N iterations directly from the layout controller:
LayoutController layoutController = Lookup.getDefault().lookup(LayoutController.class);
I pulled the latest trunk and rebuilt the Toolkit and I'm still having an issue--I think your fix took care of the inconsistency I was seeing with differing range values put in. However, I still end up with the filter being ignored but now it is consistently only happening if the MIN value is set to 1. It seems that once the MIN value goes above 1, that it filters as expected, but when set at 1, it's ignored (the partition filter is always applied, regardless).
Fix issue #69 by initializing the filters only when adding to the con…
Ok. The reason was because the original graph had a minimum degree at 1. By setting the filter [1, +inf] the system was auto adapting the minimum bound from 1 to 0 because it understood you want the minimum. This is a case I didn't think at all when designed the system.
At the end adapting the bounds is not something desirable for the toolkit but it requires to change quite a lot of things. Finally I changed some things to init the ranges only when FilterController.add() is called and not createQuery(). That should solves the problem as the range will not adapt because it doesn't know the previous value (because init was not called).