On Thu, Aug 12, 2010 at 1:08 PM, Piotr Galiszewski <[email protected]> wrote: > I have also one question about your proposal:
Please note that you don't have to accept my proposal, although I hope you understand it before deciding whether or not you like it. :) I can merge your changes as-is. > "filters_manager: remember all the extant filter definitions, allow > filters to be added or removed, and transfer them to/from the config > file. > > 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)." > > So, filter_selector should be real model for filters_view (should > contain all visible for users filters)? and model list of all > available filters? Or selector should contains similar to list filter > to current package_proxy_model list? filter_selector is the logic associated with a filters_view, or at least, the part of the logic that keeps track of which views are selected and informs interested parties. filters_view itself could fill that role, or you could separate this part of the logic into a separate code module, depending on what you think will work better. Daniel _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/aptitude-devel
