Monday, 13 December 2010

Two weeks passed since the first official Synapse release, and we've prepared another one! As common with first releases, there were quite a few issues which we worked on and fixed in 0.2.2. But besides fixed bugs we also added a bunch of stuff... So what's new?

implemented relevancy service, which makes sure that applications you use often end up among the first results of a search - this is done using Zeitgeist, so you can also track the popularity also in other Zeitgeist clients

support for basic transliteration when searching for applications - therefore you shouldn't need to type accents (if your language has them)

We also set up a wiki @ http://synapse.zeitgeist-project.com/wiki/, feel free to head over there to learn about advanced/hidden configuration options and hopefully soon there'll be even some content on plugin creation.

You can find the release tarball of Adenosine triphosphate here: http://launchpad.net/synapse-project/0.2/0.2.2/+download/synapse-0.2.2.2.tar.gz (you'll need valac 0.10 to compile it, and zeitgeist 0.6 is highly recommended to run it), Ubuntu users will find an update in ppa:synapse-core/ppa. (please note that the maverick package says that it's 0.2.1, but it's in fact 0.2.2, sorry about that).

What's next? By now we're pretty happy with the core functionality (except maybe the missing ability to configure plugins using some kind of UI), so further releases will see this fixed, and besides that there'll be mostly new and updated plugins.

Tuesday, 30 November 2010

As some of you know, during the summer I was working on a few Zeitgeist-related projects, one of them was Sezen and the panel-applet inspired by Sezen which allowed you to search Zeitgeist log conveniently from your panel. But I was never particularly happy with these solutions, and as a Gnome Do user, I was always disappointed that it is unable to find files the same way Sezen can, while the interface is pretty much a perfect fit for it. And that's when Synapse was born...

So what does Synapse do?
It well... searches stuff... If you ever used Gnome Do / Quicksilver / Gnome Launch Box, you'll feel right at home with Synapse, if not, the only thing you need to do is run Synapse (or press Ctrl+Space to summon it), type what you're looking for, and Synapse will present you a list of items that match your query. Once you found the item you were looking for, you can perform an action on it (and these are defined by the plugins you're using). If you don't like the default action, just press Tab and search appropriate action.
And besides this primary use-case, you can also browse recent items which were logged by Zeitgeist, in case you close a document by mistake or just want to hear again the music track that played a few minutes ago.

Acetyl... what?
I'm glad you agree that the release codename is just awesome, and besides that it's also a name of a neurotransmitter which transmits signals across synapse. But other than that it's an alias for Synapse 0.2.0.

How does it find stuff?
Using plugins of course - currently the development was focused primarily around using Zeitgeist for the searches, and there are even plugins that process the output from the Zeitgeist plugin and either try to improve the results, or find similar files on the filesystem (for example the Hybrid search plugin).
Still, all of the functionality is based on plugins, so further development can lead anywhere.

What plugins are available in Acetylcholine?
Current version ships with these plugins:

How to get it?
You can either download the tarball from Launchpad. Or if using Ubuntu (Lucid/Maverick) add ppa:synapse-core/ppa to your sources and install "synapse" via the package manager. Please note that you need "zeitgeist-fts-extension" (and of course zeitgeist itself - preferably with as many dataproviders as possible) to experience it the way it was meant to be. :)

I want my app to provide results for Synapse!
The easiest way to do that would be to push data to Zeitgeist (or at least to recently-used) and you've got Synapse integration for free. If you need something more complex, we'll welcome your plugin. ;)

And before I wrap this post up, I want to thank everyone involved in the development - especially Alberto, who implemented the beautiful UI and designed most of the themes; then Seif, who (after finding out about the project, despite me trying to keep it a secret from him) helped a lot to steer it in the right direction and also came up with this great name; Izo who contributed us the icon and logo; and also all of our early beta testers (especially Mikkel, who had multiple good points and Ketilwaa, great idea with the codenames).

Tuesday, 16 November 2010

how does a certain application do it's widget hierarchy in Gtk? Well lately I did, and therefore I wrote a little class that visualizes the allocation of the widget under your mouse (plus it's container). Add a little hacking with the dynamic linker and you get a small utility to inspect the widgets in (almost) any application. Take a look:

Unfortunately it's not perfect - atm it doesn't handle inner GdkWindows very well (as you can see in the video when I hover the GtkScrolledWindow), but maybe it could be easily fixed, I didn't really try as I didn't need that.
Also it doesn't work on just any application, I hooked the instantiation of my highlighting class to gtk_init(), so if your application doesn't call gtk_init(), it won't work (I'm afraid that also applies to all pygtk apps). Still, you can just compile your app with the Inspector class and instantiate it yourself.

Sunday, 1 August 2010

For the past few days I was (besides watching GUADEC talks) experimenting a little with Zeitgeist and natural language processing... or sort of anyway. Having no real prior knowledge in NL field and not using any of the existing NLP libraries (as I couldn't find anything in C), definitely made it interesting, but also made me realize that NLP is really hard (even though I only wanted to get a very specific app to work) and taking this path most likely isn't a way to get somewhere.

But anyway, the original idea was to make an algorithm which would take a natural language query and "compile" a Zeitgeist event template from it. This would make it possible to basically ask questions about stuff you did on your computer (not necessarily in a question-form) and get results back from Zeitgeist. The way I did the algorithm was very easily pluggable into any ZG application, so of course I tried it with our lovely Sezen search applet, and on the following screenshots you can see it in action:

If you for some reason don't see the images, there are queries like "music played today", "web pages accessed on wednesday" and "files modified 1 week ago". Those are basically types of strings that my simple engine is able to process right now (besides simple queries like "movies", "vector images", etc.)

I won't deny that all this work got inspired by seeing screenshots for the "Storage" project which Siegfried dug out from somewhere. And even though it seems to be long abandoned and dead, I'd still love to see its sources, but unfortunately I couldn't find them anywhere... But if you know about an URL where it still lives, please give me a shout. ;)

Also, if nothing else, this work led to a patch for Vala which fixes up bindings for N-ary trees, so soon one will be able to finally use the N-ary trees' datatypes present in glib, without having to reimplement it in Vala.

Sunday, 18 July 2010

There has been quite some work on both Sezen and the panel applet since my last post, and here's what's new on that front:

We went through quite a few design iterations of the applet, here is the evolution:

At first, we had the main Sezen widget which was stuffed in a menu, but as I mentioned in my previous post, I found this sub-optimal, as navigating in menu is not the same as doing so in a standalone window, and therefore I wanted the browser-like menu, which came to life in the third iteration, but the problem with it was that even though we had thumbnails (though not in the image), they were totally unhelpful, as they were too small. So the fourth iteration introduced three rows of text per each item, which allowed a big thumbnail on the right, but then some items had only one icon on the left, some had one on left and one on the right, and this just felt weird, so I tried to remove the icons from the left and have all of them on the right, but as you can see in the fifth image, this also doesn't look right, so the idea of thumbnails on the right was abandonded, and we ended up with medium-sized thumbnails on the left as you can see in the last image.

There are still a few loose ends in the applet (clicking on the scroll bar doesn't work most of the time, since scrollbar was never meant to be inside menu, and therefore isn't trivial to fix), and it could also use a global hotkey to popup the search. But even now I find it very usable if one has enough stuff logged by Zeitgeist.

Since Seif still thought that standard Sezen window is the way to go (with which I obviously don't agree), there's also another version of the applet, which just opens undecorated Sezen under the menu item position:

And yea, I agree that it looks nice (especially with elementary theme), but is practically unusable only with keyboard, which I find a deal breaker (also it doesn't close if you click some other window... though this could be implemented, standard menu does it automatically).

Now I wonder about the future of the applet, should we try to fix the issues it has and push it upstream, or turn it into a widget which any app can use (it'd just tell us which mimetypes it's interested in and it would augment the "Open file" function). Also which version is really better? (but please judge by using them, not by looking at the screenshots)

Sunday, 4 July 2010

As the reports themselves are quite boring for many people, I'll try to post on the blog more interesting stuff, so it will no longer be a direct copy of the message sent to gnome-soc-list. So let's give it a try...

People who read my reports know that lately I've been working on Sezen (if you haven't heard about this awesome piece of software using Zeitgeist go see a couple of videos at Seif's blog), where both Seif's python version and mine Vala version is receiving lots of love - Seif started to use Mikkel's FTS extension for the search, I didn't do this yet (as the FTS extension might not be installed), but I improved the search we had and now it's no longer that stupid (ie doesn't treat everything as exact phrase search, instead supports "quoted phrase search").

But as you could notice from the title of this post, we went further and tried to integrate sezen into gnome-panel via an applet, and this is how far I got:

At first Seif wanted to show the full sezen window also in the panel applet, but I wanted to try more "panely" look and feel and therefore went this way. Not to mention the challenge it was to get the Entry and the scrollable IconView widgets to work inside a menu (thank you Gtk for this unforgettable experience, you won a few battles, but I gotcha anyway).
If you're thinking now that it doesn't look as blingy as standalone Sezen I have to agree, but I still think that it has more integrated look with the rest of the panel and is already quite usable. I've been thinking where we could take this and I keep looking at this:

Wouldn't it be cool to have this kind of widget on your panel allowing you to start working with anything ZG knows about? What do you think?

Sunday, 27 June 2010

Another report here with a look-back at what I did this week and what is planned for the next week, so here we go:

I started to write a Totem plugin which allows searching for recent media logged in Zeitgeist, so far it's very similar to the Youtube plugin (probably because I borrowed the UI from there), but it indeed does search Zeitgeist. There were a few pecularities with the plugin, so I'll rant here a bit about the documentation - if TotemVideoList requires a reference to TotemObject, it'd be nice to mention this in the documentation - it's far from obvious that one needs to call g_object_set (video_list, "totem", totem_obj, NULL) for it to not crash when one clicks on an item in the widget. Then there were some other crashes when I didn't set "tooltip-column" property, but ok, that one wasn't that hard to figure out.
The plugin was pushed to zeitgeist-dataproviders[1], but as Seif said, it's not a dataprovider, so he removed it from there, and so far I do not know where we'll push these non-logging plugins. Anyway it's there but you have to revert to revision 78.

I helped Seif with Sezen, cause I got quite different data and it was loading very slowly for me - so I tried to use everywhere async gio calls, and after some tweaking it was working much better. Btw. Siegfried just pushed Sezen to Zeitgeist PPA [2], so feel free to check it out.

I was still quite unhappy with the responsiveness of Sezen, so I ported it to Vala [3], but to my surprise the thumbnail fetching in the Vala version is *much* slower than in the python version and I don't really know why. In both python and Vala, I'm trying to load all the thumbnails at once, and while in python this works fine, I was getting "too many open files" error in Vala, so I introduced an async method which limits how many thumbnails can be being fetched at one time (while the others are waiting) and that seems to work quite well, but I still have a feeling that the python version is faster.

For next week the plan is to implement also "related media" into the new Totem plugin, take a look on the vim logger, which I noticed is sitting on LP without being "official" part of zeitgeist-dataproviders. And talk to Seif what to do about Sezen / Sezen-vala.

Saturday, 19 June 2010

Hey everyone, this week the report will be very short, cause as I mentioned in last week's report I was (and still am) travelling, and in the little spare time I had, the internet connection was very flaky, so unfortunatelly I wasn't able to do much.

I updated the existing plugins to work with libzg 0.2 (as there were some API breaks) and I started to write a totem plugin which will show media grabbed from Zeitgeist, but in the process I encountered a very strange bug in (by that time latest) libzeitgeist, where the timestamps were truncated to 32 bits even though everything was correctly declared as gint64. This of course caused that no results were fetched from Zeitgeist - as the timestamp limited the results till the end of 1970s, and of course I don't have any such events in my DB. Anyway I wrote Mikkel about this bug with a gdb trace and he was able to hunt it down and fix it (fixed in libzg 0.2.1).

For next week I plan to finish the totem plugin and as planned for this week, I'll stop by in #rhythmbox and try to polish and fix the strange bugs in our new Rhythmbox plugin.

Friday, 11 June 2010

I'll be also a bit early this week, as I'll be traveling starting tomorrow, so here we go:

This week I finished moving the build system in zeitgeist-dataproviders[1] to autotools, and even though it's not perfect yet (can't install properly firefox and chrome extensions, mostly because I don't know where to put them in the filesystem for it to just work), it's good enough to build all dataproviders. Also if anyone wants to make a package of the dataproviders, please contact me, I think it's time to do it.

Further I had planned to write a totem extension, which would add some Zeitgeist goodness into it, but in the end this was postponed and instead I wrote a Rhythmbox plugin that adds a few smart playlists to Rhythmbox. This effort was slightly hindered by incomplete Rhythmbox bindings for Vala, but I decided to fix this and auto-generated the Vala bindings for pretty much the entire Rhythmbox, which really wasn't as easy as I expected, but it's now available on bugzilla[2].
Unfortunately I'm seeing some issues with the plugin - for example first time it's loaded it doesn't show anything, even though I am getting the data from Zeitgeist and calling RB's method to add them. I'll have to ask someone who knows the internals of RB why is that...

Also today Mikkel pushed some changes to libzeitgeist[3], so while looking at it, I discovered a little patch which was forgotten in my tree, and besides that I was trying to push some Vala goodness for the new API (foreach support), but I wasn't successful at convincing Mikkel that he needs to change the API a bit... yet :)

So that's about it, for the next week I don't plan much, as I'll be still traveling, but I hope to find some time to polish the new RB plugin, and if I find more time I'll take a stab at the Totem plugin.

Saturday, 5 June 2010

As planned, this week I finished our new Chrome extension together with the NPAPI plugin. In the end the javascript part of the extension didn't turn out to be as straightforward as I expected, but using some not-so-nice hacks it does what it's supposed to do. After I finished the Chrome extension I tried to make our new totem plugin using libzeitgeist build out of totem's tree, and fortunately this was easier than I thought it would, so it's done now and I also got some time to start to revamp the build system in zeitgeist-dataproviders [1], and even though now it's a strange mix of autotools in the top source directory and our own Makefiles in the plugin dirs, it works and currently provides the ability to detect which plugins can be build and it builds only those (note that it's incomplete, but the framework is there).

Plan for the next week is to move the whole build system to autotools, with the ultimate goal of making it possible to build packages of the dataproviders. Once that is done, I'll start to write another totem plugin, this time one which will pull data from ZG and therefore will add some UI elements to totem. Stay tuned ;)

Note to self: maybe I'm too spoiled by python, but this just doesn't work in JS (at least not when writing Chrome extension), even though there's no warning/error:

Friday, 28 May 2010

This week I've been busy with traveling and moving, but during the past few days I finally managed to work, so here's what I did:

I started implementing Zeitgeist dataprovider for Chrome (using NPAPI), but this turned out to be quite hard, as after the initial implementation the plugin was working fine in Firefox, but didn't want to show up in Chrome, there weren't any error messages and strace didn't even show Chrome trying to open the dynamic library (and strace -f was hanging)... So it was quite "fun"! Anyway today I managed to make it work and now we have a first version of Chrome extension!

Plan for next week is:

finish the Chrome extension, so it doesn't send multiple events for one website visit as it does now... Also does anyone know how to get document mime-type in Chrome?

if time allows, I'll try to make our new Totem extension to build out of totem tree, which might not be that easy to do (actually I'm not sure it's even possible)

Monday, 24 May 2010

Zeitgeist can already make users lives really easy (see my last Awn + Zeitgeist post), but we don't have to stop there, one of things I'd really like to see would be if applications helped us with this - if the apps expose which URI they are currently working with (which file is currently open / web page currently viewed / ...) we can make very precise queries as to which other files (or contacts, web pages, applications etc.) are related to this URI.

As everyone likes examples imagine that you're working with a spreadsheet and zeitgeist knows that the last time you were working with it you were checking www.sitewithstats.com, had last_years_report.pdf open and were talking to xyz. Therefore it will provide you these options in some kind of menu (or dock / indicator / windicator). Wouldn't it be great?

To make this possible I suggest new X property for windows (let's say it'd be "_NET_WM_CURRENT_URI") and the only thing required by the apps is to set this property when a file is opened and update it when appropriate. If people like this idea I can prepare a patch for gdk (adding gdk_window_set_current_uri_hint) and libwnck (which would expose the property for pagers). Or perhaps there is already something similar what I missed?

Thursday, 6 May 2010

People say that image is worth thousand words, so take a look at this video instead of me saying all those words:

Under the hood there's Awn's window to desktop file matching backed by wncksync (if available). And of course Zeitgeist with a couple of extensions which I'm currently working on.

Before anyone asks, this isn't yet pushed anywhere is now available in a separate awn-extras branch (https://code.launchpad.net/~mhr3/awn-extras/zeitgeist-applet), and will be merged to awn-extras trunk once there's an official release of libzeitgeist and everyone (read awn-testing PPA users) will be able to play with it.

Tuesday, 27 April 2010

I was looking at interesting projects where I could participate in Google Summer of Code, and the project that caught my attention was libzeitgeist - a C-based library (with Vala bindings!) wrapping the quite complex DBus interface of Zeitgeist, so I wrote a proposal and even though there were some complications and modifications, it was accepted!
Therefore this summer I'll be spending lots of time making sure that the apps that you regularly use in GNOME will have plugins which talk to Zeitgeist, so it can gather as much context of your activities as possible.

Thanks to Mikkel and Seif for loads of help already, but be aware guys that it was just the beginning :D

Sunday, 11 April 2010

It's been over 14 months the Awn and Awn Extras teams had interesting news, but the time has come to introduce our latest and so far greatest release. For the past year we've been busy with rewriting our precious dock and making it even more awesome, and today you can see the results of this work. Take a look at this screencast of various Awn settings done by moonbeam - one of our developers:

Avant Window Navigator is a dock for the Free Desktop which shows your launchers and open applications. It also contains support for extensions, via plugins for third-party applications, which communicate with the dock with DBus, and via applets, which allows for workspace switchers, system trays, clocks, etc., to be embedded in the dock. These applets can be written in Vala, Python or C.

Awn Extras is a catch-all project which houses mainly third-party applets for use with Avant Window Navigator.

I'm sure you're curious about what's new in this version, so here we go:

Awn can be finally positioned on any edge of the screen.

You can now pick among these background styles: Flat, Edgy, 3D, Curved, Floaty.

Expanded mode (Awn will cover whole screen width).

Autohide was completely revamped and Awn now supports Intellihide and Window Dodge modes.

Loading and crash indicators - no more white lines!

Added possibility to change Awn's alignment - you don't have to have it centered.

Awn tries to blend in with your theme colors by default.

Added four beautiful themes.

Most of the icons can be changed by simply dragging an icon file onto them.

Awn deprecated its old DBus interface (com.google.code.Awn) and uses now new DBus interface (org.freedesktop.DockManager). This new interface should be soon supported by other dock applications and therefore you no longer need to worry that you're writing your plugin for a specific dock.

For applet developers we have new API, check out the documentation to see what's available (usually libawn-doc package).

News for packagers:

Awn now depends on the new libdesktop-anostic library, which provides extensible configuration API, a unified virtual file system API, and a desktop item editor (all with pluggable backends).

Known issues:

Location of user settings were changed, therefore you'll need to set-up all your preferences again if you're upgrading.

Themes which were made for previous Awn versions are not compatible.

Notable changes in Awn Extras:

New applets:

YAMA: Yet Another Menu Applet that uses a Gtk+ menu for applications and preferences, has support for places, recent documents, and can lock the screen, logout or shutdown

Quit Applet: clicking can now either lock the screen, log you out, or shut down the system. You can configure the applet to display a docklet, presenting the 3 actions (lock screen, log out, shut down)

File-browser-launcher: can display multiple icons

Volume Control: uses GStreamer instead of pyalsaaudio

Weather: support for more icon themes, improvement of the preferences window, and reworked network code (improving the responsiveness of the applet)

ThinkHDAPS, Volume Control, Weather now use system theme by default and automatically respond to system theme change.

Cairo menu: rewritten, now allows adding icons for arbitrary menus.

Media Control: displays album art if available (can be set to use docklet mode)

Tuesday, 9 March 2010

As I mentioned in my last post, there has been work to create a dock-agnostic DBus API for manipulating items displayed on a dock. We now have an API draft which is implemented by latest Awn and a word from Docky's lead developer to implement the API once they have some time to do so.

As I was testing our implementation of the API, I took some of Docky's python helper scripts and converted them to use the new methods - results can be found @ https://code.launchpad.net/~mhr3/+junk/dock_scripts. So far I played with pidgin, rhythmbox, but mostly with transmission helper which now seems to me really useful. Have a look yourself:

What's next? The best thing would be to create a separate project for the dock helper scripts with some kind of configuration UI and rewrite the base python API, so it can work better (usable as both standalone scripts, but also provide a helper class for easy integration as plugins for other applications - obviously rhythmbox's helper script should be a plugin for rhythmbox to keep the memory usage down for one). And now I wonder if there are any volunteers for this... :)

I've been mostly looking over the core bugs reported at Launchpad, trying to fix them. Luckily there aren't many, which I suppose either means that we don't have enough bug-filing testers or that this release will be one of the best so far - of course I hope that the second one is the case. :) On the other hand there are quite a few bugs reported for awn-extras project (where most of our applets live) and it isn't always easy to fix bugs there, as some applets are without maintainer (for example Stacks), some maintainers are busy doing other stuff, and of course some applets would need major rewrites and people don't have time for that (Mail applet, Digital Clock, ...). Otherwise said, if you'd like to do some Awn applet development, now is the time. ;)

One of the things that I like is that there were some great updates for a few of our applets - the Weather applet is now finally doing it's networking in a separate thread, which means no more hanging mid-animation during an update and it also started to use one of our new features in Awn 0.4 - overlays - now you can clearly see when there's a network error or the actual network fetch is happening. Kudos to danni for a nice threaded processing queue for python and to onox for implementing this in Weather. Still, Weather is not the only applet using the threaded queue, and sharkbait's Feeds applet is now better than ever with this, not to mention looking great. I only hope that more python applets will try to use this (yes I'm looking at Mail applet).

What I'm personally excited about (and pushed hard to make it happen) is the agreement with Docky's lead developer DBO on a common dock item management DBus API, where various applications can add menu items to things on the dock, change the icon used (for example media-players with album arts) add some text, etc. This has been present in Awn for years, but isn't overly used and moreover the API was crappy, and seeing how everyone is excited about "helpers" in Docky (which do this exact thing) I thought having a common API for this will only benefit all dock users. Though so far the API isn't implemented by us, nor Docky, I believe this will soon change (at least on our side). Of course other dock apps are welcome to join us here.

A few days ago I started to gut our core library (libawn) and the current result is a mix of Vala and C code in there (I rewrote our core AwnApplet class using Vala) and I'm actually running this code and it works as great as the C original (even though compiling it is all kinds of weird - a special shell script instead of proper makefile rule). Ideally this branch will be base for our new major version (probably Awn 0.6) and I'd be happy if more code was rewritten to Vala, though it's not that important (the C code works fine, right? on the other hand being able to easily extend it is very good justification for using Vala). However, I also want to introduce some architectural changes and it'd be nice if some of the API that will be added made it's way also to Awn 0.4, so applet devs could play with it before 0.6 release (though stability-wise it most likely isn't a good idea). Then again, if it will be clear that the release of 0.4 will slip further into the future, I will push to merge this code. All in all, cool stuff is over the horizon!!!