Cryptkeeper in your Indicator Applet

I like the Indicator Applet and I like Cryptkeeper, so I decided to create an indicator for Cryptkeeper:

For anyone who doesn’t know, Cryptkeeper is a very useful application that allows you to mount/unmount an encrypted folder with just one click. It’s one of the most useful applications running on my startup. But up until now it had a quite ugly icon:

Can you spot the difference?

This is actually a plot to make people to like it and finish it. The patch adds support for showing and letting you mount/unmount folders, but it doesn’t let you delete folders or view information, as it did. Also, when adding a new folder, it doesn’t show up on the list if you don’t restart Cryptkeeper. But the patch does what I wanted it to (I rarely create or delete an encrypted folder), so I probably won’t change it further.

So, the patch is here. Have fun 😉

DACP in Rhythmbox: Week 2

Last week there was the inclusion of libdmapsharing in Rhythmbox (by the way, for all of you alpha testing Ubuntu, DAAP isn’t working in Rhythmbox because they haven’t included libdmapsharing in Ubuntu yet). So now I’m just a git pull and git merge away from following Rhythmbox master, which makes my job much easier.

Last week didn’t see much work from me, I was mostly fixing some bugs and some bad decisions. But I noticed I never showed screenshots of my work here. Because I love screenshots, here they are.

First you open your Remote application in iPhone, iPod Touch or Android device (note that on Android there is no passcode):

Then in Rhythmbox, you type the passcode shown in your Remote. This allows Rhythmbox to pair with your Remote:

Then Rhythmbox magically appears at your Remote list of libraries:

“DACP on Rhythmbox” will become your library’s name over time. And of course, this doesn’t fully work yet, because Rhythmbox segfaults when the iPhone tries to connect. Well, what did you expected for about two weeks of work? I was pretty excited already when I saw my iPhone on the list of devices in Rhythmbox (by the way, I think I will create a new group called Remotes, I just didn’t find out how yet).

Stay tuned for more later.

GSoC 2010: DACP Support in Rhythmbox

Community bonding is almost over so I thought I could share some details about my Google Summer of Code project.

As the title says, I will implement DACP support for Rhythmbox. You probably never heard of DACP but you’ve probably seen it in action. It’s the protocol that is used by the Remote application in iPhone and iPod Touch.

I’ll be implementing the server side in Rhythmbox, so you’ll be able to control Rhythmbox with your iPhone, iPod Touch or even your Android.

I’ll actually be implementing this inside libdmapsharing, a DMAP (DAAP & DPAP) library that was once extracted from Rhythmbox sources, improved and will be integrated again into Rhythmbox as a library, once my mentor’s patch is accepted. So hopefully, more applications will be able to support DACP, DAAP and DPAP by using libdmapsharing.

Breadcrumb in Gtk

Anyone knows how to implement (or anywhere it’s implemented) a breadcrumb / pathbar like the one in Nautilus in PyGtk? I just don’t know how to hide buttons that doent fit the window.

By the way, anyone has seen this:

That pathbar is gorgeous. It doesn’t look as good in action tough.

I’ve been using the smaller Nautilus with the Elementary theme and it is just beautiful (the picture is from Elementary Remake, the original theme with that pathbar).

Conduit GSoC

Google Summer of Code is over and I still didnt blogged about the new interface for Conduit I wrote. Well, going back to university and doing multiple things at once can really slow things down.

This shows the new UI with some conduits at the left

Ok, so this is not final but I think it’s an improvement over the old UI. The thing is, I was tired of owner-drawn widgets and I was tired of right-clicking things at the canvas (users didn’t even know that thing in the middle was the canvas). And the new UI gives me a reason to use all the work I did to rebuild the configuration system (see why dialogs was not enough?).

What I still don’t like about it, is that it’s hard to get an overview of the conduit. Sinks are usually hidden so you don’t even know they are there sometimes. I was thinking about adding a button to hide and show the configuration, but I think that is confusing and not HIG-friendly.

Another thing I’m unsure about is tabs. Everyone has tabs nowadays, do why not Conduit?

New UI with tabs

Hm, I don’t like that, it does look better but it’s rather confusing.

I do like design, but I’m not very good at it. Anyone interested in giving me some tips? Maybe someone could draw those Mac-looking mockups, that would be great!

Btw, thanks a lot John Carr and John Stowers for giving me the opportunity to work on this Summer of Code.

Conduit GSoC Progress

Thinking about another thing I’m implementing in Conduit I noticed I totally forgot to blog about my Summer of Code progress. So far there has been some hacking and fixing in several places and now I’m starting something very cool, which I really want to blog later.

One of the first things I did this Summer of Code was to improve Conduit startup time. Conduit’s dataproviders come from very different places, such as Flickr, Google, Banshee, iPods, etc. Loading all these modules is very consuming, there are a lot of dependencies and very different requirements for each dataprovider. However, most of the time dataproviders are only used to show their icons in the left-pane, so we dont actually have to load them at all before we really need them. That is just what I did. It was quite easy actually, everything seems to be architectured to do that. All information we really need from each dataprovider was already organized in a central location and in order to work with dataproviders that come and go, the entire UI handles module wrappers instead of modules themselfs, so all we need are module wrappers that load the actual modules when needed. Then on the first Conduit run, all necessary information is pickled into a file in the user cache directory (usually under ~/.cache/conduit). This file is pretty small, so it’s way faster to load then all the modules together. And if anything changes with the modules, the file is modified.

Of course, some problems arise. We really do need factories loaded all the time, those are the ones that create dataproviders for removeable devices and things that come and go (and very soon for online accounts). So I also had to split factories from their respective dataproviders. Some corner cases are still unresolved, such as our custom version of the Google library not loading everytime or the possibility of the iPod dataprovider not showing if you install the GPod library after starting Conduit for the first time (I could say “Who would do that?”, but I do sometimes 😉 I’ll probably disable the cache on these cases.

Another thing I just implemented is the ability to save and restore everything from GConf, while we only used GConf for window settings before and kept all syncset information in a XML format. This means that settings are kept updated when you make any change, such as creating new conduits and, very soon, configure dataproviders. The XML format will still be around for any DBus application to use or some future backup service.

Now I’m implementing an entirelly new UI. My idea was to use DBus to communicate with Conduit, making Conduit a true daemon process, but an idea for the new interface just popped into my head and I had to implement before I changed the DBus API for what I needed. It seems the troubles of using DBus for the GUI are greater then I predicted, but with this new UI it might be possible in the future. I’m insanely hacking at this new UI to have something 100% functional (hopefully very soon) and I’m really excited by it. I just hope the Conduit maintainers agree with me 🙂

Conduit’s improvements

As GSoC is officially starting yesterday and I made a promess to finish what I begun almost six months ago (sorry about taking so long), last week I commited the last parts of my branch. So, in the end I rewrote the configuration system of Conduit, based on a previous limited implementation that I met when working at Summer of Code 2008. If anyone wants to know if Summer of Code works, it does. I would never knew so much about Conduit had I never entered Summer of Code last year.

Why is the configuration system so important? Well, every dataprovider needs to be configured. What we do now, is that we open a configuration dialog for the user, with the standard configuration widgets: text entries, drop-boxes, item-lists, etc, and, of course, an OK and Cancel button. The problem was that every dataprovider had its own Gtk and Glade code, meaning a lot of duplicate code and usually confusing interfaces, not HIG-compliant at all. On top of that, every dataprovider showed their own configuration dialog, so we couldnt do anything else then displaying the dialog. Fixing all of this meant fixing each one of them.

I started with the idea that in order to be more useful to outside applications, we had to be more flexible and we had to fix our problems once and for all in all configuration dialogs. I knew I would have to change every dataprovider we ship, so I wanted to do it only once. In the end I created a wrapper to Gtk, letting dataproviders only deal with what matter to them. Because we have a limited set of widgets, we can have a much more useful API then dealing with Gtk directly. We also get some benefits:

• Fixing code in one place fixes it for all dataproviders.
• Being HIG compliant is much easier.
• We could change from Gtk to something else in the future much more quickly.
• We can handle configuration dialogs on clients in a much better way (think about embedding an iPod sync configuration into Rhythmbox).
• We can do something else then dialogs for configuration. Think about a sidebar, a la Glade.

It was explicitely designed for the last two points, because my first work at Conduit was the iPod module and having the same iTunes experience of syncing it was one of the main goals.

So, I wished to show a screenshot of how it looked before, but it seems we fixed so much of it lately (or we screwed up so much before) I can’t run older version. Anyway, here is a screenshot of the new code:

Picasa Screenshot

Of course, we changed a lot of code with the last commits and not without bugs. Our UI is still quite bad, but hopefully we can improve it soon.

I should start thinking about this year’s Summer of Code now. Hopefully we will have something really good at the end of the summer (my winter actually).

Introduction

Let me introduce myself, I am Alexandre Rosenfeld, a Computer Engineering student from Brazil, at the University of São Paulo. I have participated on the Google Summer of Code 2008, working on Conduit. Since then I’ve kept working on Conduit and now I’ve been selected for the Google Summer of Code 2009, to work on making Conduit a background service. Let me just say that since last year Summer of Code I’m getting involved in the Gnome community and I’m enjoying it very much.

I’d like to start talking about why I’m involved in Conduit and how I think it solves one of my favorite problems. I’ve always thought the data in my computer to be mine, just as everybody else, I think. But I always wanted to do stuff with my data, making the computer really useful. But I never could really get what I wanted without coding. So some time ago I had an idea about an application that would allow people to drag and drop components that would process their data in new and interesting ideas. This application would be kind of an script intrepeter, but without writing the script. So, as years went by, I never implemented my idea but I always found something that could be solved by my application or something that resembled it. I was very excited with Yahoo Pipes, as it resembled a lot to what I thought about the interface, but it eventually got me down as it is much different from what I had in mind.

But then I met Conduit. I allows me to pass my data from one point to another, while processing it in different ways. It even knows what kind of data it is passing around and it can make decisions based on that. The first thing I did was to try to sync my iPod, which at the time no application could do something as simple as check what songs was already in the iPod and copy songs not in there. To be honest I was creating scripts for that for a while, but running scripts in the terminal is boring. Eventually that led me to improve the Rhythmbox dataprovider, then the iPod and media classes in Conduit as part of Google Summer of Code 2008 and then I couldn’t stop having ideas for Conduit. Ok, it isn’t doing what I dreamed about, but it is pretty close and it is interesting as hell (for me at least).

Everywhere I look I see data in my computer not getting their full potential. I want a more dynamic world, a place where my data is recognized the way they are, rich, full of metadata and meaningfull to me, and it should be presented and handled like that. The reason social websites are all the hype is because they recognized that people’s data are the most precious things. People post their photos on Facebook and Orkut and it gets tagged and commented. People listen to their music on Last.fm and again, it is tagged, commented and discussed. But when you open your file manager, you get a note icon for your music and your photos appears as simple thumbnails.

Imagine if your applications could interact with your data, no matter where they are, in new and interesting ways, using their full potential? That is where I want Conduit to be, pushing data between applications, web services, devices, etc. It already knows how connect to most of them, all it needs is these things talking together. Applications should be able to use it Conduit as a data service.

My proposal is one step in that direction, bringing Conduit closer to applications. Not a big step, but it’s a start. I know a lot of people (pretty smart people) are thinking about these things, SuperDataDaemonThing, Nepomuk, Tracker, etc, and this is just my way of helping.

Google Summer of Code 2009

I have just been approved for Google Summer of Code 2009, which means I can once again work on a great project, the Conduit application.

This year my project is “Making Conduit work as a daemon”, which is by itself a great project and will allow me to implement some ideas I’m having for about a year (or at least find out why I can’t implement them 🙂 )

But what is more important is how I think it helps Gnome into better integrating the Gnome desktop with the online world. Conduit working as a daemon is much more then a synchronization application running in the background, it is a service to access any data, both local and online, indenpendently of API, language or binding, because it is available in a DBus service abstracting all the details. What is more important, is that applications dont have to implement support for every website in the planet, because that is done inside the Conduit API as modules (and plugins, as soon as I finish implementing them).

I would like to details more how all of that is possible and how I think my work can help with that, but I’ll leave that for later. For now I’m just celebrating being accepted!

Something to fix

So, this is my first post on this blog. I tried blogging before, but I never wrote much. I didnt have much to write about. But now my life is getting quite busy and I’m quite excited about many things I’m doing, so why not try to blog again.

Let’s start about the title. Well, I just wrote in the About page that I now have a focus in my life and that focus is the computer. More specifically, the human-computer interaction. I’m not only thinking about user interfaces, altough that is one area I am really interested about, but I am talking about everything that involves a computer in our daily activities. Somehow, I think the computer the way we use them now are just getting in the way. We are making people adapt to the computer, instead of the computer adapting to our workflow.

So, no, I dont know how to fix it, I just think it should be fixed. So, my focus? I want to learn as much as I can about our computer usage now. But I am not just standing still, waiting for something better to come along. No, I believe we can fix it from the inside. So I am also learning as much as I can about programming, which is one of my biggest passions, so I can actually try do something useful now.

Later on I’ll explain about how that translates to my current work.