#3119 HIGH Trial-3: Implement some basic search capabilities in the mesh view

[Zarro Boogs per Child]

#3119: Implement some basic search capabilities in the mesh view
---------------------+------------------------------------------------------
  Reporter:  tomeu   |       Owner:  tomeu  
      Type:  defect  |      Status:  new    
  Priority:  high    |   Milestone:  Trial-3
 Component:  sugar   |     Version:         
Resolution:          |    Keywords:  review-
  Verified:  0       |  
---------------------+------------------------------------------------------

Comment(by tomeu):

 Replying to [comment:6 marco]:
 > * We should gray the items out, that will avoid layout issues.

 Ok

 > * About the centering I think we should move spreadlayout inside ths
 shell (I wanted to do it anyway, it doesn't make a lot of sense to keep it
 public) and add an offset constant for the center item.

 Ok

 > {{{
 > +    def matches(self, query):
 > +        if self._buddy.is_owner():
 > +            return True
 > +        if self._buddy.get_nick().lower().find(query) > -1:
 > +            return True
 > +        return False
 > }}}
 >
 > I think filtering should really happen in the model. A simple way to do
 it would be to have a way to set a filter on the mesh model and a property
 on each child model, which the view observe. If that's not good enough for
 perf we can figure out alternative ways.
 >
 > With your current approach if something in the model change it can
 conflict with the changes you made to the view.

 I don't really see this as pertaining to the model. In my opinion,
 searches/filters can pertain either to the model or the view and,
 depending on the concrete case, will be better in one layer or the other.

 In this case, our filtering is very superficial, only affecting how we
 display the info.

 Also, the buddies or APs models should contain the logic for filtering
 themselves, and also storing a 'filtered-out' flag seems wrong to me. Also
 feels bad storing the filter value in each buddy model so it can answer by
 itself if should be filtered out or not.

 > {{{
 > +    def _add_separator(self):
 > +        separator = gtk.SeparatorToolItem()
 > +        separator.set_size_request(style.GRID_CELL_SIZE,
 style.GRID_CELL_SIZE)
 > +        separator.props.draw = False
 > +        self.insert(separator, -1)
 > +        separator.show()
 > }}}
 >
 > Can you explain why we need this? Trying to understand if it's something
 activities will need to generally do.

 I think activities don't need it because the toolbox adds some padding.

-- 
Ticket URL: <https://dev.laptop.org/ticket/3119#comment:7>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system