Testers Needed

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

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

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:

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

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

Plumbing

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:

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

1. 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.
   
2. 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.
   
3. standalone-launcher: Some initial support for specifying workspaces. An advanced edit option,
   
4. awn-system-monitor: Some fixes for sorting of process that use more than 2G of memory.
5. places: Now checks for XDG_DESKTOP_DIR.
6. 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.

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

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

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.