A rather constant theme recurs in many blog posts and forum threads. Often the statements in question are factually correct but, I think, miss the nuances of the cost involved with each choice. These themes are often framed along the lines of:

• AWN is more stable than xyz.
• Why doesn't awn have shiny feature like the parabolic zoom in abc?

Some might disagree with me but I actually think these two statements are two sides of the same coin. And it all comes down to how applets are handled in AWN versus some other docks.

There are fundamentally two approaches that can be take to applets.

1. Everything, including the dock and all the applets, run in the same process space.
2. Every applet runs in a separate process space and the dock itself runs in a process space of its own.

Now in reality it is possible to mix these two approaches. And at the moment AWN does just that; the core taskmanager/launcher applet and the separator applet are not really applets, instead when they are in the applet lists it activates code running in AWN core. This will be changing with the 0.6 release of awn when the launcher/taskmanager code will be officially moved out of AWN core into applets. (Yes I have been working on an experimental implementation of this already... but it is experimental). Obviously, some of the other docks choose a different path.


What are the tradeoffs:

• If everything is running in the same process space it's much easier to do bling. It's possible to easily and efficiently toss cairo surfaces (for example) around in a nice and shiny manner:-) In AWN's situation each applet(process) has it's very own window which makes it far more difficult to perform certain types of magic (yes we know many of you want a parabolic zoom... but it's hard, though maybe not impossible, to do with this architecture). Basically, unless we implement some compiz style window based effect engine it is necessary for each applet to handle its own effects though coordination is possible through IPC (d-bus for example), and this is what we are doing. (yes there are plans to improve this.. we have not reached the limits of bling possible)
  
• Separate processes mean more stability. If programmers were perfect this wouldn't be true. But programmers are not perfect. By separating each applet into it's own process space it makes it very unlikely that an error in one applet will bring down the whole house of cards. A shared process space situation tends to be a lot more dodgy. On the same note it makes it easier for applet devs to contribute. It's all about a low barrier of entry and there is a fairly low barrier for AWN applet developers... you don't need an indepth understanding of the internals of AWN to write an applet for it.
  
• A single process uses less resources. Even though the additional resource usage of multiple processes might not be as great as one would think, it can still be a significant cost. In the case of AWN I would have to say you pay a cost of a bit over 1 megabyte for each C applet versus a situation where everything ran in the same process. And that is a best case number.
  
• One process per applet lends itself to allowing a diverse environment for developing applets. Currently AWN supports C, Vala and Python applets and it lends itself well to the addition of others. This attracts applet devs. The more applet devs the more applets you get. And applets are good.
  

So, it really is a case of tradeoffs. I won't say with certainty which ones is the best choice... it ultimately depends on the user in question.

Been feeling kind of crappy recently but I've got a few things done.

• Most notably is simple launcher which is basically just standalone-launcher with all the interesting bits ripped out of it. All it does is act as a launcher for a single item. So those of you who don't want a taskmanager and just want launchers you can removed the taskmanager and add these. Note it will probably cost you around 2 M of memory per launcher. Personally I would prefer using standalone-launcher in mult-launcher mode...
• Added a config key /apps/avant-window-navigator/applets/shared/dialog_focus_loss_behaviour. The idea is that certain behaviors should be shared by applets. This one is to be checked by applets that use dialogs and it will control whether they should close the dialog on loss of focus. This is expected behavior in general but it messes up those who use focus follows mouse. I expect a noet about this should get pushed into the applet guidelines. Of course none of the applets have been taught about it yet.
  
• Did some cleanup of the notification daemon and finally tracked down a somewhat long-standing bug.

Other news:

• Bug fix releases of awn and awn-extras arrived on the heels of 0.2.4. So we now have 0.2.6 releases
• There's also a new comics applet courtesy of Moses.
• And some fixes went in for awn terminal.
• Pavpanchekha also has been continuing work on his mail applet, AWNlib and a bunch of small cleanups all over the awn-extras.
• More detailed summaries of what has been going on (including things I missed mentioning) can be found here and here.
  

today was my last day with OpenedHand. I'd just like to take this opportunity to say "thank you" to everyone at OH. I've had a great time working there, and learnt so much while working with people like Matthew/Emmanuele/Ross/Thomas on some of the coolest projects around.

Looking forward, I'm excited to say that on Monday I'll be starting at Canonical as a "User Interface and Applications Engineer for Mobile Internet Devices". I'll be doing the same type of work as before, with continuing work with creating/adapting Gtk & Clutter applications for mobile systems & touch-based UIs. The goal being to make sure that Ubuntu Mobile is as usable & pretty as any other mobile platform out there :-).

What is the best way to create an invisible applet/icon on the awn bar?

I've been playing around with a couple of approaches to see what gives the best results. There are three basic approaches I've been trying.

1. Set the icon to a 1x1 transparent pixbuf. It works but you still have the awn-effects related padding around it taking up several more horizontal pixels.
2. Use awn_draw_set_window_size() and set the dimensions to 0x0. If you do this you also need to combine with method 1. This seems to convince awn-effects to remove the buffer pixels... so the overall results are better. It seems to end up using 1 pixel.
   
3. Just calling gtk_widget_hide() on the applet object itself seems to have similar results to 2. There is still a visible movement in the bar when the applet is completely removed, even when it is hidden.
   

Which method to use? I'm using all 3 when hiding the standalone-launcher applets. Though either 2 or 3 alone seems to give very similar results, using the two methods together appears to reduce the chance of a visual artifact appearing if it is removed (a brief appearance of the infamous white line). Please note this is extremely hard to confirm as it tends to be somewhat difficult to test.

If you don't feel like messing around with the awn-effects stuff my suggestion is that method 3 appears to work relatively well by itself.

I would still like to have the ability to hide an applet icon in such a way as to have no visible movement in the bar when the applet is removed. If anyone has thoughts on how to do this please leave a comment. thanks.

Now that 0.2.4 has made it way out into the world I thought I'd give a woefully incomplete list of things I'd like to spend some time working on.

Awn Core

• I'd really like core to build on freebsd without needing a patch. The existence of xutils.* in the awn source is, for me at least, troubling. Besides now that we're desktop agnostic (congratulations malept) it would be nice to have a bit of platform agnostic goodness.
  
• Addition of a hide applet function in libawn. Currently when devs are hiding an awn applet we are resorting to a hackish approach, creating a 1 pixel wide transparent icon. In itself that's kind of ugly but there is also a several pixel buffer space around this pixbuf... so our invisible applet takes several pixels on the bar. Not good, and definitely something that needs to be done right.
• Review some of libawn-extras and possible move some of that functionality into libawn. I'm thinking there are several good candidates.
• Maybe spend some time on converting some existing source files to the new coding style when I'm feeling bored.

Awn Extras

• Continue to work on my experimental, out of core, launcher/taskmanager implementation.
• Notification Daemon needs some work. I'd like to put an option to have an icon displayed in the bar that would allow the display of notifications to be switched on and off. And maybe n mode where they're displayed but with a high level of transparency. Also, some general cleanups of the code need to take place including implementing Awn Config Client support, and trying to track down the odd bug.
• Shinyswitcher calls out for an xrender option. 'nuff said. And a standalone mode... I think I'd like to try it parked in the bottom left unused real estate on my screen.
  
• Cairo-menu and awn system monitor have a bunch of little bugs. And at some point system monitor really needs a rewrite. And I also have promised someone that there would be an xfce version of cairo-menu.
  
• New Applet under consideration: a configuration applet that encapsulates the features of awn-manager that I use most often :-). Awn-manager is nice but I don't like leaving it open and it takes a while to load... and I do use it quite often (mostly for starting and stopping applets).
  
• New Applet under consideration: I did say at one point in time that I'd sit down and write a SUSE style menu, however, with the appearance of a gimmie applet I think I may continue to delay this.
• New Applet under consideration: a libjana based clock applet periodically calls, and maybe I shall write one unless someone or other beats me to it.

Far to many things... umm... so how about... patches are welcome?

After many years of resisting a blog I've decided to join web 2.0. Woohoo!

Anyway, my intent is to mostly post here regarding my work with avant window navigator and its associated applets. Ah... the ruminations of another open source developer.

I'm taking a break from both trying to make a <tbody/> scroll vertically without a horizontal scrollbar present and playing "Link's Crossbow Training" to write up what's transpired in the past several days in Awn-land.

The Awn Curves branch was partially merged into awn-core-testing. I say "partially merged" because meek is merging it in parts, due to the complexity.

The big event was when Neil finished reviewing the awn-core-testing and awn-extras-testing branches and merged them into their respective trunks. Among the benefits is that users of reacocard's Ubuntu Gutsy repository can now use the shiny new features that those of us on the (very) bleeding edge have been using for a while now.

I should also point out that Neil has added both moonbeam and myself to awn-core, in recognition of our work on both the testing branches and our respective personal branches. This means we have commit access to Awn's trunk branch and more bug/blueprint triaging privileges.

As a result of the big merge, we now have a new roadmap. What used to be Neil's big rewrite for 0.3 (code-named fandabbydosy) has been spread out over several releases. See the roadmap link for details. One important item to mention is that we plan to release version 0.2.4 of both Awn and Awn Extras on Monday (02/18).

In Awn Extras, most of the changes have been bugfixes. A patch was added to the media-control applet for Quod Libet support.

Finally, I'm holding a contest for Awn users/enthusiasts. In the near future, I'd like to have a post with screenshots and videos showing off all of the new features and applets in Awn/Awn Extras. Unfortunately, I suck at doing that sort of thing myself. :) So, I'm giving the Awn community the chance to show off their customized docks.

The only restriction on the screenshots and videos is that you license them under a Creative Commons license. I will, of course, attribute all media to their proper creators :) Ideally, the screenshots should be as hi-res as possible, but any resolution is welcome. The same goes for videos.

The deadline is Feb. 21, because I'd like to write the post by the end of next week. I'll choose a set of media that looks the nicest (with the help of the people in #awn) and use that as the basis of my next Awn post.

So if you wish to participate, please post the URL to the media, the attribution information you wish to use (your name or nick), and which feature/applet you're highlighting on the forum thread or as a comment here.

Given the lack of releases of Awn, I figure that there needs to be some record of what's happening in Awn-land ever since we got version 0.2.1 of Awn and awn-extras out the door, other than the mish-mash of posts on the forums.

Awn

Here's a (most likely incomplete) list of the new features in awn-core-testing, mostly taken from the branch whiteboards:

• A simple mouse wheel task scrolling implementation
• Sort applets in alphabetical order in awn-manager
• Xfce support (build flag: --with-desktop=xfce4)
• desktop-environment-agnostic support (build flag: --with-desktop=agnostic): this requires GLib 2.15.x and above, because it uses the new GIO library to replace the GnomeVFS code.
• GKeyFile configuration backend support (build flag: --without-gconf): this adds a compile-time option to build a .ini-style configuration backend, instead of GConf.
• Freedesktop.org Desktop Entry wrapper API: Desktop entry files are used all over the place in both Awn and awn-extras, so I wrote an API that wraps both the GnomeDesktopItem and EggDesktopFile APIs, depending on your desktop preference. Note that the Xfce backend also uses EggDesktopFile, because I found out that libxfce4util's desktop entry implementation was read-only, and read-write-support was needed.
• File/directory monitoring wrapper API: The Gnome implementation uses GnomeVFS, the Xfce implementation uses ThunarVFS, and the agnostic implementation uses GIO.
• Python bindings for all of the new APIs
• Vala bindings (auto-detected at build time)
• remove the gnome-panel dependency by writing a launcher/desktop entry editor in Python (including custom/stock icon chooser)
• changed awn-manager applet interface

Note that everything except the first two items are also in my desktop-agnostic branch.

awn-extras

Since the 0.2.1 release, a number of new applets and other changes have occurred in the awn-extras tree.

New applets

• Affinity (yes, that Affinity)
• Arss (Applet to view feeds)
• Awn Terminal
• Cairo Menu
• Clock/Calendar
• Comic
• Digg
• Digital Clock
• File Browser Launcher
• Last.FM
• MiMenu
• Mount
• Pandora
• Places
• PyClock
• Shiny Switcher
• Standalone Launcher, Taskmand, Taskmand-applet: an alternative to the built-in launchers and task manager.
• Terminal Services

Other changes

• Rewritten build system
• Shared libraries for applets to use: libawn-extras (with python bindings) and AWNLib (for Python only)
• The GMail applet has been renamed to the Mail applet and has been completely rewritten. As a consequence, it no longer uses libgmail.
• Stacks: experimental GUI
• BlingSwitcher: Due to the lack of both a maintainer and a license, this applet will most likely be removed from the tree. However, an archived copy will be linked on the forum and the wiki.

Distribution support

Our resident Debian/Ubuntu packager, gilir, successfully got Awn (the dock) into the official Hardy repositories, specifically universe/gnome, as avant-window-navigator. Unfortunately, there are some QA problems with the awn-extras applets package, awn-core-applets, but gilir is working very hard to get that resolved before the package freeze. He is also working on getting said packages into Debian sid.

Meanwhile, in Gentoo-land, there are official ebuilds for both Awn and awn-extras, named gnome-extra/avant-window-navigator and gnome-extra/avant-window-navigator-extras, respectively. Since the xeffects overlay is defunct, I'm working with the team behind the desktop-effects overlay to get the awn-core-testing and awn-extras-testing branches in as working "live" ebuilds. Of course, this comes after I was alerted via an awn-extras bug that one of the desktop-effects developers described the build system as piss-poor. Being the author of the new build system, I was a bit offended. Luckily, the lead developer for that overlay was more level-headed than the stereotypical Gentoo developer whose comment started it all. I'm still waiting for an apology from said developer, but I'm not holding my breath.

Wiki

A community member has contributed a wiki for our project. We've been using it for both end-user documentation (Installation, FAQ) and internal processes. In particular, the applet developers have been collaborating on some applet development guidelines which should be followed if a person would like their applet to be included in the awn-extras tree.

Other

In non-Awn/Awn Extras news, there have been reports that the Gimmie project has added Awn applet support, in addition to its current support for the gnome-panel.

---

The changes I've listed for Awn and AWN Extras are currently being reviewed so that they'll be merged into trunk in the near future. In the meantime, you can grab the test packages from the Awn Testing Team's PPA (for Ubuntu users), install Awn and Awn Extras from the desktop-effects overlay (for Gentoo users), or simply install from source (making sure that you uninstall any previous version of Awn/Awn Extras first!).

Well I spent the better part of a day trying to install Gutsy Alternate via USB. The Gutsy live cd works fine but it seems there is the ‘Where is the cdrom?’ problem when using Gutsy Alternate. I have finally succeeded in getting it to work correctly so I thought I would share the [...]

(@flickr. Created at O'Reilly Maker [Via Ajaxian]. Under a CC-BY-SA license.)