moonbeam's shiny, bleeding edge, blog

New addition to awn-core

2011-02-16T12:47:00.003-05:00

Just a quick welcome of onox to awn-core. Onox has long been a fixture in extras with many applets and extensive work on awnlib. Onox initially will be applying those skills to Awn Setting, followed, we're sure, by other interesting contributions.

Live previews in awn taskmanager

2010-12-14T18:57:00.004-05:00

A WIP. After many months I finally got around to doing some work on this recently.

As an additional note... I'm looking for work - eastern Ontario, western Quebec, Canada - any leads are appreciated.

Per dock/panel intellihide configuration in taskmanager.

2010-11-06T15:19:00.003-04:00

Just mentioning... awn (taskmanager) now supports per dock/panel configuration of intellihide.

New Blood!

2010-06-21T21:07:00.002-04:00

Just a quick welcome to sharkbait (aka Matt) and Alberto to Awn core.

Context Menus Can be Fun!

2010-01-09T01:59:00.004-05:00

Just a quick screencast of the XML based context menus. You can define the menu if you want.

So you like Network Manager...

2009-12-03T14:47:00.000-05:00

Just a tease.

Awn-testing packages and Cairo-menu rewrite

2009-10-23T23:31:00.004-04:00

So as you may be aware the awn-testing ppa is now providing packages based on rewrite code. Note that this does not mean that we've merged rewrite into trunk quite yet. We haven't been flooded with bug reports yet, I'm not really sure if that's a good or a bad thing.

I've been doing some work on the cairo-menu rewrite. Just working on getting the gnome menu up and running properly at the moment. Note the startup notification support (which I added in at the same time as I was doing it for Taskmanager) I will also be adding a xfce menu option (it will be possible to switch menu library at runtime). Beyond this, I also intend to have a custom rendering mode for menus that will override the standard gtk menu appearance... I suspect this is going to cause me massive headaches.

Anyway, here's a screencast. For some reason gtk-record-my-desktop has become gtk-record-a-slideshow... so I had to use xvidcap, the results are acceptable, but not great.

Expand the bar to emulate a panel

2009-09-16T22:43:00.005-04:00

For those who, for some bizarre reason, miss their panel we offer an option to expand the bar. Which in conjunction with the new expander applets allow a fair amount of flexibility in the layout of the bar.

And here's the screencast:

Next post, I'll probably return to talking about the taskmanager and some of the choices regarding the default configuration.

Taskmanager, Disabling Icon Changes.

2009-08-24T18:56:00.002-04:00

If you don't like apps marring your carefully chosen icons by trying to provide information, then it is possible to disable this behaviour. Making use of the disable_icon_changes key can keep the icon specified in the launcher's desktop file in place at all times (if there is no desktop file then the taskmanager will continue to use the icons provided by the application).

Taskmanager: Customizing Icons

2009-08-24T18:00:00.004-04:00

So, A quick tour of the new Taskmanager Customize Icon feature.

A few notes:
1) Only available when desktop lookup has been successful or there is a Launcher. (The goal is for desktop lookup to work, so I'll treat failures as bugs instead of changing this requirement... at least for now).
2) Available through context menu. Taskmanager is diverging from the standard drag and drop an icon file mode. With good reasons, This will keep the drag and drop of files into a launcher sane (the application is invoked with those files).
3) I think icon issues should be dealt with in the installed icon theme. But as we know there are always egregiously ugly misses with icon themes and not everyone has the knowledge/time/rights/inclination to modify their chosen icon theme. So we have this.

Taskmanager Window Grouping

2009-08-22T20:23:00.006-04:00

Continuing with our little screencasting extravaganza here's a clip that demonstrates grouping behaviour with gnome terminal, OpenOffice and Gimp.

As an additional note the following have been pushed into Taskmanager in the last day;

1) Drag of files over windows (activating the window).
2) Drag and drog.
3) Customize Icons context menu item.

So you like your Taskmanager classic?

2009-08-22T15:23:00.002-04:00

Continuing the demonstration of various configurations of 0.4 Taskmanager.

This is, more or less, the classic 0.[123].x behaviour. Next up, a closer look at grouping.

So You Don't Want Your Launcher to Manage Your Windows?

2009-08-21T12:17:00.010-04:00

Assuming you don't want grouping, this is quite easily done in rewrite. Just set Match Strength to 0.

See the screencast below:

I'll be posting a series of screencasts showing specific configurations. Including grouping/non-grouping and a few other Taskmanager configurations.

What are Your Thoughts on Taskmanager Behaviour?

2009-08-20T14:54:00.002-04:00

I've started a topic on the awn forums about the rewrite taskmanager behaviour and configuration options. Well, we are all to well aware that a consensus is not likely to be reached on this topic we do would appreciate opinions and observations. We'd like to discover what features people like/use and what they don't. Feel free to share your preferred configuration.

We're looking for things that need to be tweaked and to determine what our default configuration should be for the 0.4 release. And obviously any bugs that are uncovered would be a useful.

So head over to the thread and give your opinion.

Intellihide in awn

2009-08-11T23:18:00.004-04:00

Implemented Intellihide in the Taskmanager applet today, making use of the new awn panel dbus interface to inhibit autohide as needed. At the moment it closely follows the documented behavior of Docky Intellihide as originally devised/implemented by our good buddy DBO. I believe the only variance is that awn checks all the open windows on the current workspace instead of only the focused application's windows. We may end up switching it to mimic the Docky behaviour after I've discussed it with other awn devs. My preference is obviously this way but, I probably won't end up using this feature in the long term so I'm rather easily swayed.

And here's the screencast.

Universal Applets support merged

2009-07-17T22:54:00.003-04:00

The code supporting Universal Applets in Avant Window Navigator has been merged into the rewrite branch (A thank you goes to mhr3 for taking time to cleanup the dbus implementation today). I must say that gilir has been plugging away trying to get some headway on this project for a while, and it probably would never have gotten done if he hadn't taken the time to get the UA side of things, plus dbus interfaces all setup, so when us C types had the inclination, things were nicely primed.

What this merge means is that with the 0.4 release we have basic support (AwnApplet level more or less) functionality for most universal applets in the panel. Now certain screenlets obviously are not good candidates (some are meant to be much larger than the bar) for this, but a fair number are. And I have some thoughts for those other screenlets for the post 0.4 code :-)

Now a few notes:

AwnApplet level functionality... means no effects and no reflections. I'm hoping reflections will eventually show up for AwnApplet applets (probably 0.6) at which time UA/Screenlets should get them also. Effects, I would not be expecting anytime soon.
The UA/Screenlets code to support this is not yet in the main UA branches. They reside in some of gilir's branches. Hopefully this will show up in the UA trunks real soon. There is also a possibility that the necessary code to support this may show up in Screenlets proper (as opposed to the UA fork) at some point, though I really have no idea on what the timeline for that might be or even that it's a 100% certainty.
This is the an initial implementation. I think it's fair to say that various aspects can be improved over time... but the it seems the basics are fairly solid.
There is at least one awn side issue that I am aware of... that being curved style. I'm sure that a few others will rear their heads up.
Ultimately this should be regarded as just another option. Especially useful if you're missing one or two items in your suite of awn applets that just happen to be covered by a screenlet or two.
There are some outstanding bugs/issues on the UA side of things. I have made sure that aantn is well aware that they need to be fixed :-) The most pressing issues in order of importance:

Periodic issues with mouse events. This has been around for a while AFAIK. I looked through the UA bugs and didn't find it... but I'm sure it's lurking in there somewhere. To sum up, periodically some screenlets top receiving mouse events. I'll also note that I have not seen this happen yet with one that is currently embedded in the awn. I have a sneaking suspicion that this one is proving difficult to resolve. So the bug is not connected with awn per se... but it is a rather significant usability problem.
UA Screenlets that were previously embedded in awn do not remember to reattach after they are restarted. This code is only present in Gilir's branch at the moment but obviously needs to be resolved. I expect this can be fixed quite easily.
A dbus api to allow awn to inform a screenlet that it should not reattach itself to awn (probably reverting back to the default behaviour of connecting to melange). This will allow screenlets to be "permanently" removed through awn-manager. Till this is done it will be necessary to configure screenlets to not reattach (after (2) is fixed) using the standard UA interfaces. My guess is that it's not a huge problem, just a matter of defining the api, implementing it on the UA side of things after which we can plug it into awn without too much difficulty.
I believe that there are also a few concerns about the making the dbus api a little more flexible in terms of it's design that mhr3 has voiced. These issues are something that are relevant but not vital in the near term.

Another screencast

2009-06-30T00:30:00.001-04:00

Here's some Awn/UA integration work that's being worked on. And yes there are still a few glitches.

Applet Devs: Rewrite will be hitting trunk soon. How will your applets cope?

2009-06-23T15:27:00.003-04:00

Just a heads up. The rewrite branches will be merged into trunk some time in the next few weeks.

Core-rewrite: https://code.launchpad.net/~awn-core/awn/trunk-rewrite-and-random-breakage

Extras-rewrite: https://code.launchpad.net/~awn-extras/awn-extras/extras-trunk-rewrite-and-random-breakage

Notes

There may still be some API churn after the merge but it shouldn't be _overly_ severe. Things might get added but hopefully what's there won't change much.
Onox has done a fair amount of work in extras rewrite converting converting awnlib to the API changes. So if your applet uses awnlib your work may be relatively minimal.
Doing a trivial conversion of an applet can be as simple as a few minutes work. Do take the time to test with multiple orientations etc.
A lot of extras pplets have already been converted.
Once we merge rewrite, awn-testing ppa packages will soon follow. Meaning applets that have not been converted will stop working for any user of the awn-testing ppa.

This is just a heads up to start looking over rewrite, and possibly start taking advantage of some of the new things that are available in libawn. As always, if you have any questions please feel free to post here or drop by #awn on freenode.

A quick screencast

2009-06-06T00:34:00.002-04:00

This previews some of the current features of Awn rewrite including mhr3's new Edgy panel style. Expect various details to change by release day including the preference dialogue.

That is all.

If Neil gets around to blogging I guess I better do so also

2009-05-27T22:18:00.002-04:00

Just a quick update on things in the world of Awn.

Things seem to be picking up again as various real life commitments slow down for the various devs. I'm even finding some time to do some work. At this point in time we're getting close (weeks) to merging rewrite back into trunk. Which will mean packages in the PPA. Which will mean legions of testers. heh.

I've been spending my Awn dev time working on the system monitor rewrite. I'm quickly becoming a fan of AwnIconBox... The rewrite has multiple graph types, multiple icons per applet (cpu usage, load average etc) and a much cleaner design which will lead to eventually monitoring everything!

Over the next week or so I'm also hoping to dump the first iteration of AwnOverlaidIcon which will allow easy/consistent overlay of pixbuf/surfaces and text on applet icons. The hope is that this will allow a bit more consistency between applets for these use cases. This may also help push forward the implementation of plugin support in rewrite.

At the moment I believe the main blockers for merging rewrite back into trunk are:

Opening/Closing animations in the taskmanager.
Panel resize animations
Plugin support.

Regarding Awn plugin support... the consensus at this point seems to be that we do want to dump big chunks of the old API and implement something a wee bit nicer. So, we will be deprecating plugin API during the 0.4 series.

That's it for now.

A quick update

2009-02-07T16:22:00.004-05:00

Let's see...

Been rather busy in recent months.
Started back to work with a small company that I've been involved with for close to a decade. It's nice... getting to work on everything from kernel level code through to shiny frontends. The negative side effect is that my awn dev time has been rather reduced.
My awn dev time has mostly been devoted to the rewrite branch side of things, though I have backported a large number of fixes to shinyswitcher, cairo-menu and places to trunk.
Yes a 0.3.2 release is imminent, seemingly largely lead by mhr3 but with contributions from quite a few others :-). See this and this.
After 0.3.2 I think it fair to say that attention will begin to focus heavily on 0.4... I'll try and write a bit more about that sometime soon.

icons, icons, icons

2008-07-13T18:15:00.004-04:00

So I've been working on awn-icons recently. The goal to provide a standardized way to change the icons used by applets (and eventually tasks/launchers).

I'm feeling lazy so I'l just point to a couple pages.

Sharkbaitbobby has made a nice little write up that is of most use to python devs but is definitely worth reading for others.
There's also a blueprint.

Todo:

Clearing of configured icons.
Look into using this with the awn core taskmanager/launcher.
Convert more applets.
Hook up some signals so changes in icons get reflected in all awn-icons users immediately.

Testers Needed

2008-06-09T11:20:00.003-04:00

Things have reached the point where I'd now like to get some testers for cairo-effects. If there are any issues/suggestions please post on the forum.

awn-cairo-effects

2008-06-08T13:10:00.002-04:00

So I've done some work on my awn-cairo-effects branch in the last few days.

This initial work more or less involves replacing all the pixbuf related code in awn-effects with pure cairo code - a task that is progressing. I've decided to take a somewhat iterative approach to this work. Instead trying to completely replace the whole awn-effects engine I'm trying to replace bits and pieces.... I guess we'll see how that turns out.

At the moment there's no real point in trying my branch unless you modify an applet to specifically access the code in question. However, I expect within a few days the old awn_draw_icons() will become a thin wrapper to awn_draw_icons_cairo() in which case it'll be time for testing... whether all current effects will be implement at that time is up in the air ( saturate being real PITA I'm thinking).

Shinyswitcher and standalone-launcher

2008-05-25T13:01:00.003-04:00

A lot of the work I've pushed recently has very little visible effect for most users. Yet. It's basically been a lot of reorganization with the goal of future, shiny, goodness.

However, in recent days, I've pushed a few commits that do have a visible effect:

I've modified the default configuration of Shinyswitcher to be more pleasing in a wider range of Window Managers. By default it only grabs an image of the currently active window, this will more or less get rid of the black square issue that happens with a lot of configurations. The maximum time for updates has also been lowered from 30 seconds to 7, so corrupted grabs won't tend to linger as long. I've also defaulted the layout to 3x2, remember that this only applies to non-compiz configuration... if compiz is in use it will use whatever config compiz is configured with. I've also tweaked some of the scales and opacity values. As always the configuration values can be changed in the normal place. And yes I do know that a configuration utility is needed for shinyswitcher.
Standalone-launcher will now bring the managed task to the foreground when a drag and drop motion occurs on the icon. So if you grab an icon from you desktop and drag it over a nautilus task it will activate the nautilus window. If the applet is managing multiple open windows it is possible to cycle through them by moving the pointer and and off the icon (this is a temporary behavior which will be replaced by opening up the task list dialog eventually).

A quick note on vala support. Currently we require version 0.1.7 or 0.2.0 of vala. Versions > 0.2.0 will not work. At this time the newest version is 0.3.2. We anticipate upgrading when vala 0.3.4 arrives, though this is not a firm decision... it could happen with 0.3.3 or even, though hopefully not, a later version.

Other (not necessarily an exhaustive list) news:

aantn continues to make progress on Universal applets.
Tehk has pushed his rewrite of arss into awn-extras.
malept continues work on making the trash applet gvfs aware.

Plumbing

2008-05-18T19:15:00.003-04:00

Still keeping rather busy with non-awn related things. But I have managed to do a few things here and there :-)

Things I have been up to...

Some plumbing changes in awn core:

Committed the refactor of the src/xutils* related code. This removed a large chunk of unused code from xutils.c and made some modifications so that FreeBSD builds (and potentially other) work. I was rather pleased to set #161028 to "fix committed". And yes... this has lead to a different default icon being used when awn is unable to find a match. Speak up now if you are unhappy with this.
Pushed my reorganization of awn-effects.c code. I'm not done with it yet but it basically broke awn-effects.c into multiple source files and began work on chopping some of the larger functions into more manageable sizes.

A bunch of small fixes/changes in awn-extras:

libawn-extras: Make it real simple to access shared key values... Several applets now used the shared key that specifies whether the applet dialog should close on loss of focus or not. The list of applets that are now using this include awnterm, awn-system-monitor, places, main-menu and (I believe) any applet using AWNLib.
awn-notification-daemon: Basic toggling on/off of notification window display which is available if one configures it to display an icon. If anyone likes to design icons please read my request.
standalone-launcher: Some initial support for specifying workspaces. An advanced edit option,
awn-system-monitor: Some fixes for sorting of process that use more than 2G of memory.
places: Now checks for XDG_DESKTOP_DIR.
webapplet: malept and myself have also done some initial work on a simple webapplet. It's quite basic at the moment but the initial design seems fairly solid and I believe it will end up being useful. It is necessary to either use the awn-testing ppa to get it or to build with --with-webkit. Yes it is webkit based at the moment but the longterm plan is to allow the use of webkit and/or gtkmozembed.

Things others have been up to (probably not as complete)

What else has been happening in awn land...

pavpanchekha continues work on AWNlib. It really is a good idea to use it if you're starting a new python applet.
aantn continues his work on Universal Applets. This is really quite cool. And hopefully he'll push some support into awn for this some day soon :-)
malept continues to do numerous bits of magic with the build system and has done numerous conversions of applets to awn config client, various bug fixes and has been working on converting the trash applet to gvfs... meaning the problem with the Trash applet on Hardy will soon be fixed.
Yes the weather applet had an issue recently. It has been fixed in trunk. This affected a lot of weather applets out there and was due to changes made by weather.com. Mosburger quickly restored everything to working order.
gilir continues to make progress of insinuating awn into Debian and Ubuntu and has added a tomboy applet of his own creation to awn-extras.
Moses had committed several useful fixes/features to the comics applet.
Matt continues to work on the file-browser-launcher.
Andrewsomething's recent Remember the milk applet seems to be quite popular.
tehk has returned after a several month absence is beavering away on a new and improved arss. Showing up in trunk real soon.
There are also several new applets available only on the forums that will, hopefully, soon make there way into trunk.

I've almost certainly have forgotten some interesting things... if so just leave a comment.

Yeah... I've been getting very little done in the AWN world.

2008-04-12T21:25:00.004-04:00

I'm hopeful that I will be able to start getting some things done this week. First thing on the list is looking at the Vala 0.2 release vis a vis the vala applets. I'm not anticipating it being overly ugly (insert superstitious action here).

Beyond that I'd like to make a real life observation. If you ever fall in love with a full blown BPD sufferer then don't be ashamed to say enough is enough early on and get the Hell out.

A Generic HTML Applet

2008-03-22T21:15:00.005-04:00

Life has decided to sneak up and pound me over the head with a large, heavy object recently... consequently I haven't gotten a lot done in awn land. And don't necessarily expect to accomplish much in the the next couple weeks.

That being said I have started some work on a generic HTML applet. In a fit of originality I have called it webapplet. It is in awn-extras but it will not build unless you use the --with-webkit configuration option. You will need to have webkitgtk installed as it is a webkit only beast at the moment. I also don't believe the configure script is checking for webkitgtk at the moment... I'll need to nicely ask malept to look into that for me.

Anyway, it's not doing a lot at the moment but it does have some ambitions:

Try to stem the proliferation of hundreds and thousands of individualized web applets :-)
Option of webkitgtk and/or gtkmozembed renderer. I will not add the gtkmozembed until after I am happy with the webkitgtk implementation.
Support for as many of the web widget formats as possible. And yes there is an intent to support Apple Dashboard widgets if possible.
Ability to easily configure it for new pages/widgets.
A collection pre-configured pages/widgets. I'm thinking stored in a keyfile backend. The goal is for the user to start up the configuration and be able to either choose from a selection of pre-configured options or add their easily own.

Anyway, just something I've been working on a bit when I've been in a coding mood. I'll post more as it progresses.

PS njpatel has been making a few interesting commits this weekend.

Why things are the way they are...

2008-03-09T22:12:00.007-04:00

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.

Everything, including the dock and all the applets, run in the same process space.
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.

Simple launcher and other news

2008-02-25T16:18:00.004-05:00

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.

Invisible icons

2008-02-20T19:57:00.005-05:00

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.

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.
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.
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.

Things to do

2008-02-19T21:57:00.003-05:00

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?

Hello world

2008-02-17T17:49:00.000-05:00

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.