Thursday, December 3, 2009

Friday, October 23, 2009

Awn-testing packages and Cairo-menu rewrite

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.

Wednesday, September 16, 2009

Expand the bar to emulate a panel

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.

Monday, August 24, 2009

Taskmanager, Disabling Icon Changes.

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

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.

Saturday, August 22, 2009

Taskmanager Window Grouping

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?

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.

Friday, August 21, 2009

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

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.

Thursday, August 20, 2009

What are Your Thoughts on Taskmanager Behaviour?

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.

Tuesday, August 11, 2009

Intellihide in awn

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.

Friday, July 17, 2009

Universal Applets support merged

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:
  1. 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.
  2. 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.
  3. 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.
  4. 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.

Tuesday, June 30, 2009

Another screencast

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

Tuesday, June 23, 2009

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

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




  1. 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.
  2. 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.
  3. 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.
  4. A lot of extras pplets have already been converted.
  5. 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.

Saturday, June 6, 2009

A quick screencast

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.

Wednesday, May 27, 2009

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

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:
  1. Opening/Closing animations in the taskmanager.
  2. Panel resize animations
  3. 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.

Saturday, February 7, 2009

A quick update

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.