It's been a while since there were some interesting Awn news from me, but fortunately moonbeam has been filing the gap with his posts on the task-manager popup menu customization and also his work on network-manager adaptation for use in Awn.
I've been mostly looking over the core bugs reported at Launchpad, trying to fix them. Luckily there aren't many, which I suppose either means that we don't have enough bug-filing testers or that this release will be one of the best so far - of course I hope that the second one is the case. :) On the other hand there are quite a few bugs reported for awn-extras project (where most of our applets live) and it isn't always easy to fix bugs there, as some applets are without maintainer (for example Stacks), some maintainers are busy doing other stuff, and of course some applets would need major rewrites and people don't have time for that (Mail applet, Digital Clock, ...). Otherwise said, if you'd like to do some Awn applet development, now is the time. ;)
One of the things that I like is that there were some great updates for a few of our applets - the Weather applet is now finally doing it's networking in a separate thread, which means no more hanging mid-animation during an update and it also started to use one of our new features in Awn 0.4 - overlays - now you can clearly see when there's a network error or the actual network fetch is happening. Kudos to danni for a nice threaded processing queue for python and to onox for implementing this in Weather. Still, Weather is not the only applet using the threaded queue, and sharkbait's Feeds applet is now better than ever with this, not to mention looking great. I only hope that more python applets will try to use this (yes I'm looking at Mail applet).
What I'm personally excited about (and pushed hard to make it happen) is the agreement with Docky's lead developer DBO on a common dock item management DBus API, where various applications can add menu items to things on the dock, change the icon used (for example media-players with album arts) add some text, etc. This has been present in Awn for years, but isn't overly used and moreover the API was crappy, and seeing how everyone is excited about "helpers" in Docky (which do this exact thing) I thought having a common API for this will only benefit all dock users. Though so far the API isn't implemented by us, nor Docky, I believe this will soon change (at least on our side). Of course other dock apps are welcome to join us here.
A few days ago I started to gut our core library (libawn) and the current result is a mix of Vala and C code in there (I rewrote our core AwnApplet class using Vala) and I'm actually running this code and it works as great as the C original (even though compiling it is all kinds of weird - a special shell script instead of proper makefile rule). Ideally this branch will be base for our new major version (probably Awn 0.6) and I'd be happy if more code was rewritten to Vala, though it's not that important (the C code works fine, right? on the other hand being able to easily extend it is very good justification for using Vala). However, I also want to introduce some architectural changes and it'd be nice if some of the API that will be added made it's way also to Awn 0.4, so applet devs could play with it before 0.6 release (though stability-wise it most likely isn't a good idea). Then again, if it will be clear that the release of 0.4 will slip further into the future, I will push to merge this code. All in all, cool stuff is over the horizon!!!
I've been mostly looking over the core bugs reported at Launchpad, trying to fix them. Luckily there aren't many, which I suppose either means that we don't have enough bug-filing testers or that this release will be one of the best so far - of course I hope that the second one is the case. :) On the other hand there are quite a few bugs reported for awn-extras project (where most of our applets live) and it isn't always easy to fix bugs there, as some applets are without maintainer (for example Stacks), some maintainers are busy doing other stuff, and of course some applets would need major rewrites and people don't have time for that (Mail applet, Digital Clock, ...). Otherwise said, if you'd like to do some Awn applet development, now is the time. ;)
One of the things that I like is that there were some great updates for a few of our applets - the Weather applet is now finally doing it's networking in a separate thread, which means no more hanging mid-animation during an update and it also started to use one of our new features in Awn 0.4 - overlays - now you can clearly see when there's a network error or the actual network fetch is happening. Kudos to danni for a nice threaded processing queue for python and to onox for implementing this in Weather. Still, Weather is not the only applet using the threaded queue, and sharkbait's Feeds applet is now better than ever with this, not to mention looking great. I only hope that more python applets will try to use this (yes I'm looking at Mail applet).
What I'm personally excited about (and pushed hard to make it happen) is the agreement with Docky's lead developer DBO on a common dock item management DBus API, where various applications can add menu items to things on the dock, change the icon used (for example media-players with album arts) add some text, etc. This has been present in Awn for years, but isn't overly used and moreover the API was crappy, and seeing how everyone is excited about "helpers" in Docky (which do this exact thing) I thought having a common API for this will only benefit all dock users. Though so far the API isn't implemented by us, nor Docky, I believe this will soon change (at least on our side). Of course other dock apps are welcome to join us here.
A few days ago I started to gut our core library (libawn) and the current result is a mix of Vala and C code in there (I rewrote our core AwnApplet class using Vala) and I'm actually running this code and it works as great as the C original (even though compiling it is all kinds of weird - a special shell script instead of proper makefile rule). Ideally this branch will be base for our new major version (probably Awn 0.6) and I'd be happy if more code was rewritten to Vala, though it's not that important (the C code works fine, right? on the other hand being able to easily extend it is very good justification for using Vala). However, I also want to introduce some architectural changes and it'd be nice if some of the API that will be added made it's way also to Awn 0.4, so applet devs could play with it before 0.6 release (though stability-wise it most likely isn't a good idea). Then again, if it will be clear that the release of 0.4 will slip further into the future, I will push to merge this code. All in all, cool stuff is over the horizon!!!
You can confirm docky is committed to this API. Though we might want to have another round of discussion on it.
ReplyDelete