Filters are addictive! (GSoC 2010 Week 3)

The last two weeks I have spent a bit more time than I expected playing with filters, filters and more filters. The first iteration went in maybe a bit too quickly, so I have done quite a bit of clean-up. Python is being too lenient with me!

I’m finally pulling my head out of the code and looking at this from further back, and from here things are looking pretty cool. There is still a lot of stuff in the implementation that needs fixing, but it is entirely possible to start playing with something else without wasting any effort.


Yes, that bar on the left is for controlling the filters! Clicking on a filter toggles it, which is done by loading a new URL with the appropriate parameters appended so Harvest knows what to do. The debug toolbar is reminding us that performance is still pretty ugly, but most of those SQL queries are from the opportunities list below each package. Some time in the next few weeks I will be moving that feature so it only appears on demand.

As for the other filters, those are coming. At this point it should be pretty easy to get a rough implementation of everything that is on the left side in the mockup. They won’t be pretty, but they should work. Just extend one of the Filter base classes, add a custom function for manipulating a queryset, override the render function if desired, and it’s done!

All the HTML stuff for that filters bar had to be implemented in Python, rather than the template. It’s the same kind of design as Django’s own forms module, so I think it is forgiveable…

Speaking of filters, I’ve developed a dangerous obsession with The GIMP’s collection of goodies. Quite proud of this rendering I made for a friend. It’s proof he looks exactly like Tintin!

It was straight-forward to do. I used the toon filter and oil painting filter to add outlines and soften the details. Then I whipped out the trusty liquid rescale to make his face a little taller (which worked beautifully given that the other details were insignificant). Finally I did some extra brush work to mimic Herge’s drawing style, making colours more solid and connecting some lines.

In the end it’s probably too subtle, and it would have been easier (though slightly less exciting) to draw it from scratch. Still, it was an interesting exploration. I look forward to doing this to more peoples’ heads in the future.

Making Harvest awesome! (My GSoC 2010 project) — Week 1(ish)

It is time that I babble about my project for Google Summer of Code 2010!

Over the summer, I will be working on Harvest with Daniel Holbach as my awesome mentor. Harvest is a neat web service, built with Django, that brings together opportunities (things that need doing), from many different places on the web. Those opportunities are all neatly linked to source packages, which are, themselves, nicely described by package sets like ubuntu-desktop, unr, xubuntu and kernel.

Suffice it to say, Harvest is a huge database with a lot of intricate detail. It can be really helpful to see all this stuff in one place. My task is to implement views that harness all that data and resist the temptation to throw it all at the user at once. The result should be really helpful, quick and fun to use. (This may be difficult; I can be a very wordy person).

The first stage to achieving that is filters.

I’m using an existing wiki page as a starting point, which has one very pretty mockup. I created a mockup of my own, full of crazy tangents and marked by the single worst green pencil I have ever used.

There are a few crazy and opinionated things I want to do. First of all, I want to go as far as possible without a numerical paging system. Numerical pages make no sense. The second thing I want to avoid is a detached searching system; I think searching could be integrated pretty smoothly with filtering, so everything on the site works under the same rules. Third, while I want this to work really well with Javascript, it has to work well without Javascript.

Last week I continued familiarizing myself with Harvest, and I made a start on the back-end for the filtering. I am building a generic structure that describes all the filters and what they do in terms of database queries. This way we can change the mechanics or add new filters quite easily (and have them do all sorts of neat things), and we’re secure from people executing arbitrary operations on Harvest; only filtering operations that we define can be run.

The actual visual portion of the filtering stuff is entirely detached, and it is non-existent at this point. I expect the rest will be easy to pop together once the back-end is in place.

So, yeah, not very exciting yet. It’s Harvest, and the list of packages is filtered. The URL format is, of course, not at all decided but it’s most likely going to carry parameters with GET. That way people can link straight to Harvest showing a particular query. The one for that screenshot is /opportunities/filter?pkg=name,set&pkg_name=ge&pkg_set=ubuntu-desktop,core, which describes a package with a name that starts with “ge” and belongs to the “ubuntu-desktop” or “core” package set. I would love to know if that looks sane to anyone but me :)

Exciting, eh?

This week I will be doing a bit more with the invisible half of the filtering system, then I’ll make a start on the user interface half. Still nothing pretty (yet), unless the urge overpowers me; just drawing the widgets and having them do the right thing when they are clicked. I want to test my approach before it’s stuck that way.