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 🙂