Bugsquashing and paint attributes
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 http://lists.beryl-project.org 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.
Well, yes, 0.1.5 was definitively coming too fast.
I’m sure we will all help you to do the best release possible.
Hopefully, we won’t be late for 0.2.0
Comment by Ago — January 15, 2007 @ 8:28 am
HI..
I ve noticed some bugs, about apps behaving weird accross Desktop enviroments.
I suppose… well it is more possible that for ex. firefox, is going to behave not as expected at gnome, because epiphany is it’s default browser.
Same, for expample goes for Asm, (cozz it uses tcl y tk) , it won’t have a perfect interaction neither in Kde or gnome ..
in other words there is no Gui/Desktop integration, if the user prefers other apps rather than defaults.
¿What’s you opinion about this?
Comment by Euskal — January 28, 2007 @ 11:52 am
Nah, it’s more the design of the app. In my experience, ff kinda likes to do it’s own thing, seems like it wants to be the only app to run and that the wm and de should revolve around ff. Examples of that is the lack of proper wm_class on the menus, and some resize/maximize “tricks”.
Asm I don’t really know, but other apps that I feel like to do their own thing is openoffice… There are a number of applications that doesn’t properly follow the EWMH, just follows it enough to work under traditional setups…
Comment by kristian — January 28, 2007 @ 2:44 pm
hehe ff is the only browser I know that has a autoscrolling image
hope moz-devs resolve the fuzzy redraws on aiglx before 3.0.0 9_9
Comment by Euskal — January 28, 2007 @ 9:02 pm