Kristian Lyngstøl's Blog

Bugsquashing and paint attributes

Posted on 2007-01-15

Ok, so we tried arranging a bug squashing weekend and we did get a noticeable ammount of bugs squashed, but the turnout wasn't quite as good as we had hoped for. We fixed a few tickets, closed a few invalid ones, classified a few and got more assigned. We might do this again in the future though, but for more than just a few hours on a saturday.

It became more and more obvious that we would have to delay 0.1.5 a day or two, for a couple of reasons. One of them is trailfocus 2, which strictly speaking would be trailfocus 3. It's a complete rewrite from scratch of trailfocus motivated by the excessive CPU usage of the trailfocus that lie in trunk at the moment. It did, however, revive a discussion I had with onestone at the time I wrote opacify about methods of changing paint attributes. Basicly, we both agree there needs to be a proper way of doing it, but we've yet to agree on what way we should do it. See ( for the discussion details. (dev-list)

The idea is to make it easier for plugins to deal with opacity-changes(or saturation/brightness) in a natural way. So far, there hasn't been much of a standard, I went a bit against the wind with opacify to avoid having to calculate opacity on every paintWindow, which is how it is done on the old trailfocus-rewrite. We hope to also agree on a solution to make it easy and natural for state to override paint-changes (like exclude windows from opacify or trailfocus)

A few other reasons for the delay is snap and awaiting a unified decision on thumbnail2. Strictly speaking we're beyond a new plugin freeze, but snap is a release criteria for 0.2.0 so that has been known all along, and there are compelling arguments for thumbnails2 too. Either way, 0.1.5 will be important, and the feedback we get from it will be vital for the quality of 0.2.0.