[Aptitude-devel] aptitude-qt VCS usage and code review

[Piotr Galiszewski]

2010/7/16 Daniel Burrows <dburrows at debian.org>:
> On Fri, Jul 16, 2010 at 01:10:43PM +0200, Piotr Galiszewski <piotr at galiszewski.pl> was heard to say:
>> 2010/7/16 Daniel Burrows <dburrows at google.com>:
>> >  This is effectively what all the other frontends do, except that
>> > they only support one predicate (aptitude match expressions)
>> > and they don't have a separate class for holding the search
>> > predicate and updating the view when it changes.
>> >
>> >  BTW: I would be perfectly happy with just having the filter hold
>> > a match expression and use that to search.  These extra layers
>> > of indirection are only needed because you seemed to want to
>> > use non-match-expression predicates.
>> >
>>
>> It will be one of my next step to implement aptitude's search syntax.
>> Probably I will borrow some code from generic/apt/matches/match.cc and
>> make it work with package class
>
>  You shouldn't have to implement anything or borrow code from generic/.
> All you need to do is hand a string to the parse routine, catch any
> errors you get back, and the pass the matcher to the match routine.
> For input handling, there's a controller/view pair named "search_input"
> that will do the parsing for you, so you just operate at the level of
> search expressions.
>

Thanks I will have a look on it

>> P.S. Probably I am the most problematic and annoying student in this
>> year soc. Sorry about that ;)
>
>  I know I'm a pretty "hands-on" mentor, and I know I'm probably slowing
> you down with all these annoying requests for design changes.
>

It is not a problem. Thanks for all of this :) Thanks for that I am
learning a lot of new things. As I wrote in my mid-term evaluation it
is probably code with the best qualify I have ever written :) I am
sure this experience will help my with my future work and education

I have implemented basic searching based on new filter classes and
pushed it to the repo. Some refactoring is needed (write docs, maybe
split some patches, and make filters_model use abstract interface
patter - all other managers uses this, so I think this should use this
too)

Now, I will try to measure performance of new code, and compare to
older implementation. Without numbers it seems that searching by name
and maintainer is really fast. Only searching by long description is
visibly slower than in previous version. Is is strange because there
are no conversion between string and QString as I decided to use
normal strings with boost::ifind to compare strings. Probably I made a
mistake in some place.

>  I expect that this first bit of the project is where I'll be most
> involved, because I really want to make sure that the core part of the
> design is clean and that we have some reasonable middle-ground
> established between Qt and aptitude idioms.  Once you start implementing
> individual tabs, I think things will go faster -- it's less important to
> get them right the first time, since they can generally be rewritten
> without too much disruption after the fact.
>
>  Daniel
>
> _______________________________________________
> Aptitude-devel mailing list
> Aptitude-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/aptitude-devel
>

-- 
Regards
Piotr Galiszewski