[Aptitude-devel] Review of 298143

Daniel Burrows dburrows at google.com
Tue Aug 3 23:34:59 UTC 2010

On Tue, Aug 3, 2010 at 4:18 PM, Piotr Galiszewski <piotr at galiszewski.pl> wrote:
> 2010/8/3 Daniel Burrows <dburrows at google.com>:
>>  The natural design for me would be to have the proxy model have a
>> single filter, and have some other component keep track of what it is.  e.g.,
>> maybe the list of available filters has a signal saying "the filter
>> has changed",
>> which is emitted whenever the selection changes, and which automatically
>> bundles up all the selected filters into an OR / AND as appropriate.  That feels
>> more proper than having the package list know what multiple selected filters
>> mean.
> So there could be one more similar class like filters_manager?

  The idea in my head was to divide responsibilities like this, but
maybe with a better name for the new class.

    filters_manager: remember all the extant filter definitions, allow
filters to be added or removed, and transfer them to/from the config

    filter_selector: tracks a list of filter definitions that is being
presented to the user and emits a signal when the effective filter has
changed (either due to a change in the selection or to a change in a
selected filter definition).

    package_proxy_model: uses a single filter (not definition) to
select which packages are displayed, which can be modified

  That centralizes the slightly tricky state management in a single
class (filter_selector), letting package_proxy_model concentrate on
calculating the final package list.


More information about the Aptitude-devel mailing list