It has been a long time between posts, but I am back in New Zealand now, and vowing to get back on top of this blogging thing. I will post more in the coming weeks about my time in France with the ENAC crew, but I will start today small; by releasing some code I have been hacking on.
I wanted a small project to get back into the desktop development mindset after being in the embedded C (ARM 7 LPC2148) and OpenEmbedded (Beagleboard and Gumsix Overo) world for a while. I am also ecstatic that git was clearly the most popular DVCS in the recent survey, I really hope it provides the impetus for GNOME to move to a DVCS.
With that in mind I decided to use this small project to learn git. Firstly, github.com is the coolest thing I have ever seen. I am moving all of my projects (except Conduit) there, and using the pages and wiki features to document them as appropriate.
Facebook Notify
Facebook Notify is a small PyGtk application which monitors your Facebook profile and notifies you when it changes. Some would consider it a gross abuse of the GNOME notification area, but it keeps me out of the web browser, decreasing procrastination, thereby improving my productivity.
It notifies you when any of the following events occur;
-
One of your friends changes their status, profile picture, or profile details
-
You receive a friend request, event or group invitation
-
Someone writes on one of your friends walls
-
One of your friends is tagged in a photo
The code is a few days work, and nothing impressive. It does however contain a rather nifty deferred threaded network io system so to never block the GUI. I guess something similar could be done in C + libsoup + GTask, if one was allowed to arbitarily chain callback functions. I remeber seeing a bug and discussion about this somewhere.
The main bug is that WebKitGtk segfaults if you destroy the WebView after logging into Facebook. Not cool. Anyone know anything about this bug? Is anyone going to make an updated libwebkitgtk release soon?
So, please, fork my code. That way I have a real life example to practice merging from!
Wahoo!, after mad busy weeks of development, I just released Conduit 0.3.4. Check out the screencast (download here). This release is fresh with new features, and heaps of polish and integration work. These new features include;
-
Google calendar support (Paul Novotny).
-
Youtube dataprovider added (Renato Araujo).
-
Photo sites are now two way, you data is no longer locked with one provider. Also see #480754 for improvements to Fspots DBus interface allowing two way photo sync with FSpot.
-
Nautilus extension. (disabled by default).
-
EOG plugin added. (disabled by default).
-
Conduit now supports resizing and converting photos before uploading them to photo sites. This infrastructure means improved support for other types of conversions, such as transcoding music and video, will be added in the future.
-
Progress indicator shows percent complete during synchronization.
-
Add support for Facebook photo upload.
-
Add included web browser for authenticating against web sites.
Website Authentication
The last point deserves some explanation. Currently, to authenticate against some sites the user must log in either once (Flickr), or once per session (box.net). This is difficult when using the system default web browser, if the browser is currently running on a different virtual desktop to conduit, the user often doesnt notice the web browser go to the login website. This is compounded by the different APIs of some sites. Flickr is good, I can just call am_i_authenticated(token) in a loop, and wait for success, or time out. Facebook is not good. Any call involving the facebook token before it has been validated (i.e. user logs in) invalidates the pending login. Because there is no guarenteed way to block in all cases (i.e. until the user logs in and closes the window), things like gnome.open_url() or python.webbrowser() are unsuitable. This leaves me with two options. I can wait a random amount of time, and hope its long enough for the user to log in, or I can write my own web browser that will block until the user closes it. Suggestions for option 3 are appreciated....
I know this is not ideal. I hope something like web-login-browser can solve my needs. Also, I know my gtkmozembed based browser has some (crasher..) issues (maybe related to this). I hope to fix them and/or move to a pywebkitgtk based browser, depending on what GNOME favors.
Here is a screencast showing the latest version and its features. You may download the original here. Apologies for the google video quality.
[googlevideo]http://video.google.com/videoplay?docid=-262844619875208739&hl=en[/googlevideo]
Boston Summit
Unfortunately, owing to my proximity to the opposite side of the world as Boston, I will not be attending the summit. I understand that the GNOME online desktop is on the agenda, and will no doubt be discussed at some length. I hope those involved in the discussion try out conduit before the summit, as it would be a shame if the future of the GNOME online desktop was set without due consideration. This is not a criticism, sour grapes, or anything like that. Its just a reflection of what appeared to happen after GUADEC - which I also did not attend (New Zealand = isolated and distant).
Have fun with Conduit. Please report bugs, join the mailing list, and abuse me at will. We are currently moving to GNOME servers, so if my server goes down from all the traffic I promise it will be the last time.