Re: [Weekly report] Week 5: Conduit
- From: Alexandre <airmind gmail com>
- To: John Stowers <john stowers gmail com>
- Cc: Conduit <conduit-list gnome org>, gnome-soc-list gnome org
- Subject: Re: [Weekly report] Week 5: Conduit
- Date: Tue, 30 Jun 2009 05:18:12 -0300
On Tue, Jun 30, 2009 at 00:31, John Stowers
<john stowers gmail com> wrote:
On Tue, Jun 30, 2009 at 2:10 PM, Alexandre
<airmind gmail com> wrote:
I had my last exam friday, I still have some things to deliver but I had some time to hack on Conduit this weekend.
Basically I hacked on the login centralization on Conduit. This is important because users dont want to type their username and passwords all the time, so this brings on place to add accounts to Conduit. What I did was to create a factory that handles listing accounts and creating dataproviders for them. My initial test with the Google and Flickr dataproviders worked, but there is still much to do. My feeling is that technically, this is quite simple, but I still dont know the best way to present it to the user.
Right now I have some alternatives: keep the dataproviders as is and let the user choose an account when it adds the dataprovider to the Canvas, or create categories or new dataproviders for each new account, similar to how devices are shown, so the user chooses which account to use by dragging that account to the Canvas. The former is how this is being implemented, for no real reason.
This work is especially important for my project, because imagine the user trying to upload his image in Eye of Gnome to his Flickr account, the last thing he wants to do is authenticate with Flickr all the time.
That sounds great. How is the data stored behind the scenes, in gnome-keyring or somewhere else?
Using Gconf (/apps/condut/Accounts/module_name/account_name if I'm not mistaken, similar to how I'm trying to keep a list of persistent SyncSets in /apps/conduit/SyncSets/syncset_name, so we could refactor the code later on).
Gconf lets me watch for changes, so my idea of implementing a GUI (which doesnt exist yet) is simply changing the GConf values, so both the GUI and the AccountManager I created see the changes. A pure-Python implementation would be very simple, I could use GObject signals for changes.
But of course, the real place to store these are in the keyring, so I'll look in to how to access it this week. Shouldnt be very hard.
Btw, the code is in the gsoc2009_alexandre branch. I'm basing all my work in that branch because it's easier to fix earlier bugs.
Also, great 0.3.16 release :) I loved to see my work being released. I hope I fixed everything I had to fix for the release.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]