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

Since we're trying really hard to get Awn 0.4 into a usable state with all the glory and most of the applets we had in the previous releases, I'll try to describe the important changes that happened in the API, so it's easier to convert existing applets to work in 0.4. Please note that if you were using onox's awnlib, the conversion should be painless, because it wraps libawn API and therefore applets did not need to be modified (but I might be wrong, onox will know better).

If you're interested in an article about how to write an actual applet from the beggining, I do plan to write that too, so check back later.
I also plan to write an article about the completely new functions/methods/classes, so you'll have to wait for that a bit as well.

Note that for the sake of simplicity I'll be using pythonish syntax, even though I mostly write C code, so here and there the class names etc. might more resemble C.

So here is a quick list of the most important changes:

1. AwnApplet was completely revamped - now its base class is GtkPlug (as opposed to GtkEventBox) and it handles connecting to main Awn process, sending signals to whoever is interested, etc.
   
2. therefore AwnPlug died.
3. many (if not all) of AwnAppletSimple's methods were renamed.
   
4. AwnAppletDialog is now AwnDialog.
5. AwnTitle got also renamed to AwnTooltip.
   
6. the job of AwnIcons now handles AwnThemedIcon (which is part of AppletSimple).

And now to show you some actual code, I'll help myself by looking at the modifications that were needed to get media-control applet to work in 0.4 (thank you `bzr diff` for making this easy):

I'll start with the AwnApplet(Simple) constructor. In 0.2 (note that I use 0.2 for Awn versions 0.2.x and 0.3.x, since the API was pretty much the same) you'd have:

class MyApplet(awn.AppletSimple):
def __init__(self, uid, orient, height):
  awn.AppletSimple.__init__(self, uid, orient, height)
  # do stuff

# creating an instance looked like this
if __name__ == '__main__':
awn.init (sys.argv[1:])
applet = MyApplet(awn.uid, awn.orient, awn.height)
# ...

This will now be:

class MyApplet(awn.AppletSimple):
def __init__(self, uid, panel_id):
  # of course you can pass also the "applet-name", that's up to you
  awn.AppletSimple(self, "applet-name", uid, panel_id)
  # do stuff
  # to get the former "height" ie. size of the applet, you can now do:
  size = self.get_size()

# creating an instance is now:
if __name__ == '__main__':
awn.init (sys.argv[1:])
applet = MyApplet(awn.uid, awn.panel_id)
# ...

Now let's talk about the methods of AppletSimple:

# imagine we have "self" an instance of awn.AppletSimple
# these commonly used methods no longer exist:
self.set_title(text)
self.set_title_visibility(bool)
self.set_icon(pixbuf)
self.set_icon_context(cairo_context)
self.set_awn_icon(applet_name, icon_name)
self.get_awn_icons()

# but you can use these instead
self.set_tooltip_text(text)
# if you want to show tooltip on mouse-over and hide it on mouse-out you DON'T
# need to call these, there are properties of AwnTooltip which handle it.
# this means you probably no longer need to connect to enter/leave-notify-events
# and show/hide the tooltip manually
# (for more info see "smart-behavior" property on libawn API pages)
self.get_tooltip().show() or self.get_tooltip().hide()
self.set_icon_pixbuf(pixbuf)
self.set_icon_context(cairo_context)
self.set_icon_name(applet_name, icon_name)
self.get_icon()          # returns awn.ThemedIcon

# and now the commonly used methods of AwnIcons:
self.get_awn_icons().get_icon_simple_at_height(height)
self.get_awn_icons().get_icon_simple() # returned icon with size equal to 48

# is now:
self.get_icon().get_icon_at_size(size)

As for "awn.AppletDialog", the only thing you need to do is to substitute it for "awn.Dialog".

And that's it, these are all the changes that had to be done for media-control applet and it should hopefully help you convert your applet.

P.S.
Our API is still not officially "frozen", so there could be some more changes, but we will try to minimize them, for me the only unknown is malept's config client (awn.Config) which probably will need to be renamed, since it will be now part of libdesktop-agnostic, but other than that its API should be more or less compatible.

Also current version of libawn API can be currently found at http://www.stud.fit.vutbr.cz/~xhruby16/libawn/.

Edit: There was one more change to the AwnApplet constructor, now you need to pass canonical-name for the applet as first parameter. The code above was updated to reflect this change.

Weirdness which I can now attribute to "PHP Library Hell" (similar to DLL hell) had caused the full text of posts for most of the feeds to not be syndicated in the planet feed for several weeks. This is now fixed. (I had to upgrade to Wordpress 2.8 for the actual error to appear and a solution to be presented, it seems.) I apologize for the inconvenience.

Hi there, and thanks for stopping by at my blog.

So, I'll start by introducing myself - I'm a computer science student, who participates in a couple of open source projects. Currently I'm spending most of my open source development time working on Awn (avant-window-navigator), which is a shiny dock/panel for *nix platforms.

As one of Awn's core developers, I noticed that we don't have many tutorials on how to write Awn applets and such, and people usually have to turn to existing code. This might not always be the best source of tips, so I'll try to fill in the gap... There are also many interesting ideas flowing in the Awn-land, so I'll try to share some of them from time to time. Other than that... well who knows what will come to mind and what I'll have desperate need to share with the world. :)

And that's about it for the start, expect a real Awn-related tutorial soon.

About three weeks ago, it was exam studying time for me. I had a list of 60 mostly unfamiliar vocabulary terms to know for the exam. A bit of googling brought me to WordNet. I wrote a simple Python script to quickly retrieve the 60 definitions from the downloaded version and output everything to a single file. Then, I had to memorize all these terms, so I wrote a simple flash cards app in Python + Gtk. I decided to expand this simple app into what is now Memorizer.

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

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.

The first draft of my GNOME Journal article on Zeitgeist is below. Criticism and comments are welcome.

Zeitgeist is a data engine for the GNOME desktop. It logs and tags every document, website, conversation, email, note and application that’s opened on the GNOME desktop. All of the information is stored in one central database for quick access and any application can easily add it’s own data to the mix. There are several user interfaces which show the information stored in the database, sorting it by type, date, or relevance to other files. They let users tag documents, bookmark them, and even attach custom notes to each item in the database. One of the interfaces, currently being developed by Siegried Gevatter as a GSoC project, even shows information from Zeitgeist inside the new GNOME Shell.
 
Zeitgeist was founded eight months ago after the GNOME User Experience hackfest in Boston. The first prototype was based on Mayanna/Gimmie and had only two regular developers who hacked on it in their free time. Today, we have a whole new codebase and there’s already six developers who commit code on a regular basis and several other community members who help test Zeitgeist, handle bugs, and design mockups for future user interfaces. The Zeitgeist team recently presented at the Ubuntu Developer Summit and Zeitgeist is slated for adoption in future versions of UNR (Ubuntu Netbook Remix). Zeitgeist is also going to be used in the as-of-yet unreleased Ubuntu Parental Controls and is even at the heart of a thesis paper and a PHD research paper at a German university.
 
Parts of Zeitgeist are based on ideas from the “Document Centric GNOME” presentation which Federico Mena-Quintero gave at GUADEC 2008. His ideas inspired a journal and a calendar interface for Zeitgeist which lets users view files that they edited at previous points in time. In accordance with some observations made by Dave Richards at the User Experience hackfest, some of the Zeitgeist interfaces hide filenames and directories from users in an attempt to free them from worrying about where files are located on the hard drive. Instead, users can tag the files and find them based on what type of file they are and what other files they’re related to.
 
However, the current user interfaces for Zeitgeist don’t even give users a hint of the real power which lies dormant under the surface. Our current goal is to index as much information from as many different sources as fast as we can. Once that’s done, it’ll be easy to build exciting new user interfaces which pull information out of Zeitgeist’s database and display it to users in all sorts of innovative ways. For example, it should be possible to let users build their own interfaces where they define what documents they want to see and how they want those documents to be organized. For example, one recent mockup lets users build custom “Smart Feeds” which aggregate together all sorts of different files according to user-defined filters. [1]
 
One of the key concepts in Zeitgeist is that users care about “Documents” and not “Files.” In other words, users don’t want to be bothered with the distinction between documents that are on their computer (files) and documents that aren’t on their computer. Therefore, we have plans to index documents from online sources such as Google Documents, Flickr, and Launchpad. In a world where everything is online, there’s no reason why file managers should focus only on local files!
 
The biggest question that we’re currently trying to answer is what’s next. We’re already planning on adding on support for optionally using Tracker or CouchDB as a backend in place of our own database. The aforementioned “Smart Feeds” are also on the development map along with UbuntuOne integration, LAN powered “Shared Feeds,” and support for associating people with documents. However, we’re a versatile bunch and after that anything is possible.
 
Zeitgeist is about humans- especially people like you and me who like technology and want to make a better user experience for everyone. We care just as much about the team work and the international cross-culture collaboration that drives our work as we do about the end product that we ship. We love to see new faces and hear new voices. A lot of our best mockups are scribbled in love on the back of cafe napkins, which just goes to show that you don’t need fancy paper or great artistic skills in order to innovate. We’d love to hear your voice as well. When we’re not sleeping, we live in the #gnome-zeitgeist channel on irc.gnome.org and will soon have our own website up at zeitgeist-project.org. We look forward to seeing you and hearing your idea for GNOME 3 and the next generation user interface. Welcome to Zeitgeist!
 
[1] See http://natanyellin.com/2009/06/14/zeitgeist-mockup/

 

I’ve been thinking about the proper way to handle fulltext searches in Zeitgeist. (E.g. searching through a file’s content instead of just searching for files by name.)

I think the best solution is to fall back to Tracker and other search engines for all text searches. This is especially important if we index things like GMail emails where we can’t possibly handle all searches ourselves without downloading and indexing all emails. (Instead, we would just index each email’s title and sender. If the user performs a search, we would use GMail’s API to find results on the fly.)

On that note, I’m planning on adding Google Documents and Flickr support. This probably wont happen until later this week or the beginning of next week

I’m sitting at the Coffee Bean with a large Ice Mocha. Things that I’ve been working on include:

1. The GNOME Journal article on Zeitgeist which is due today.
2. An improved version of the mockup which I posted last night. (The new mockup is still only on paper.)
3. I discussed this bug with Ketil.
4. I’ve been thinking about how to handle fulltext searches in Zeitgeist. I’ll post about that later.
5. I’ve bought the domain name natanyellin.com last week. I’m going to start redirecting theesylum.com to natanyellin.com later this week.

Time to get back to work. One large Ice Mocha down and one salad to go.

I came up with a quick mockup for Zeitgeist last night. (Yes, it’s bare, hand drawn, and full of squiggly lines that are supposed to be straight.)

Comments are welcome. If enough people find it interesting, I might write some code for it this week.