Re: ThreePointOne: Contacts
On Mon, 2011-04-18 at 09:29 -0700, Travis Reitter wrote: > As Frederic pointed out, we shouldn't be brainstorming on the 3.2 > feature pages, so I thought I'd fill in some details/thoughts on the > Contacts [1] idea here. Cool. Matthias put me down as Owner of that feature, because I will be spending lots of work time on it to get something good for 3.2. However, I'm kind of a newbie in this area, so I'd like to start reaching out to the involved parties and take a look at the technologies involved and their status. It seems like we have lots of interest and momentum from the telepathy/folks/socialweb side. Do we also have interested parties from the evolution side? I think having this deeply integrated with evolution is as important as the IM/social side. Ideally we should be replacing the evolution address book UI with this. > * Folks has a nearly-ready read-only e-d-s backend [2] > * making this read-write should be straightforward, since we did that > with our Tracker backend This sounds excellent. It seems to me that we should default for this to be the main writable store, and avoid using the keyfile backend. Its our primary local contact store anyway, so why not also use it to link to other personas. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a scrappy Jewish shaman on the edge. She's a vivacious paranoid magician's assistant who can talk to animals. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Mon, 2011-04-18 at 11:52 -0700, Travis Reitter wrote: > On Mon, 2011-04-18 at 20:29 +0200, Johannes Schmid wrote: > > While using GNOME 3.0 on my desktop now for a week I wanted to share my > > thoughs on the UI. The problem in the current situation is that the > > shell provides a nice chat integration but to start a new chat you have > > to use the "Contact List" window of empathy which feels totally > > out-of-place. It is also one of the windows you really don't want to see > > in the overview. > > Agreed. I'd like my general chat process to just be: > > , + By meta you mean the "windows key" thing? > which is the same way I launch all my applications in Gnome Shell (and > is one of the most compelling features of it, I think). Like launching > programs, you would be able to pause to see the full results list and > perform more-specific actions (such as selecting the exact account and > contact you want to initiate the chat from and to, as Empathy lets you > do now). Yeah, this sounds like about the right thing. I'm thinking we could have a new tab in addition to the windows and applications one listing people, probably showing the online ones first, or at least making that information prominent. Clicking on a person should let you easily send mail, start a im conversation or send a file. Additionally these should show up on the search results, and be possible to put in the dash. > > What Daniel and Salamon mocked-up is certainly a nice start but I think > > a dedicated window for it doesn't fit with the overall shell design > > well. > > I think it makes sense to have both. The shell search provider would > focus on communicating with existing contacts (similar to launching > programs), whereas the stand-alone program would be more focused on > adding and managing contacts (which are much-rarer actions). And it > still makes sense to have the communication buttons in the stand-alone > program to make the use case of "add a person, start chat/call with > them" smoother than adding them there, then going to the Activities tab > to start the communication. Yeah, I think this is somewhat analogous to the file management situation. If you just want to find or open a file you can use the shell, but if you want to do more work you'd start the file manager. So, the gnome-shell integrated part is about day-to-day using of the already set up stuff, whereas the contacts app is where you'd fill in information, or do more complex stuff like link contacts or create groups. There are other integration points we must think about too. Whatever we come up with should imho replace the contacts pane in evolution, and must allow interaction with evolution (dnd onto composer windows, etc). Also, we should have something that corresponds to clicking on the "to" button in the evo compositor to select a single email (or im if used for elsewhere) address to add. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a scrappy small-town stage actor fleeing from a secret government programme. She's a disco-crazy hypochondriac wrestler married to the Mob. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Mon, 2011-04-18 at 09:29 -0700, Travis Reitter wrote: > http://lists.freedesktop.org/archives/telepathy/2011-March/005369.html > [4] This seems to talk about querying contacts from slow social web services. Additionally if this is to be our story in evolution too we need to be able to efficiently handle ldap contacts, which are really important for enterprise deployments of email. This also needs a live search approach, because we can't rely on a local copy of all ldap data. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a one-legged Jewish senator whom everyone believes is mad. She's a warm-hearted impetuous vampire with a flame-thrower. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 10:01 +0200, Alexander Larsson wrote: > On Mon, 2011-04-18 at 11:52 -0700, Travis Reitter wrote: > > > On Mon, 2011-04-18 at 20:29 +0200, Johannes Schmid wrote: > > > > While using GNOME 3.0 on my desktop now for a week I wanted to share my > > > thoughs on the UI. The problem in the current situation is that the > > > shell provides a nice chat integration but to start a new chat you have > > > to use the "Contact List" window of empathy which feels totally > > > out-of-place. It is also one of the windows you really don't want to see > > > in the overview. > > > > Agreed. I'd like my general chat process to just be: > > > > , + > > By meta you mean the "windows key" thing? > > > which is the same way I launch all my applications in Gnome Shell (and > > is one of the most compelling features of it, I think). Like launching > > programs, you would be able to pause to see the full results list and > > perform more-specific actions (such as selecting the exact account and > > contact you want to initiate the chat from and to, as Empathy lets you > > do now). > > Yeah, this sounds like about the right thing. I'm thinking we could have > a new tab in addition to the windows and applications one listing > people, probably showing the online ones first, or at least making that > information prominent. Clicking on a person should let you easily send > mail, start a im conversation or send a file. Additionally these should > show up on the search results, and be possible to put in the dash. > > > > What Daniel and Salamon mocked-up is certainly a nice start but I think > > > a dedicated window for it doesn't fit with the overall shell design > > > well. > > > > I think it makes sense to have both. The shell search provider would > > focus on communicating with existing contacts (similar to launching > > programs), whereas the stand-alone program would be more focused on > > adding and managing contacts (which are much-rarer actions). And it > > still makes sense to have the communication buttons in the stand-alone > > program to make the use case of "add a person, start chat/call with > > them" smoother than adding them there, then going to the Activities tab > > to start the communication. > > Yeah, I think this is somewhat analogous to the file management > situation. If you just want to find or open a file you can use the > shell, but if you want to do more work you'd start the file manager. > > So, the gnome-shell integrated part is about day-to-day using of the > already set up stuff, whereas the contacts app is where you'd fill in > information, or do more complex stuff like link contacts or create > groups. > > There are other integration points we must think about too. Whatever we > come up with should imho replace the contacts pane in evolution, and > must allow interaction with evolution (dnd onto composer windows, etc). > Also, we should have something that corresponds to clicking on the "to" > button in the evo compositor to select a single email (or im if used for > elsewhere) address to add. Empathy uses the “text/individual-id” and “text/persona-id” drag targets for dragging and dropping folks individuals and personas. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 09:53 +0100, Philip Withnall wrote: > On Tue, 2011-04-19 at 10:01 +0200, Alexander Larsson wrote: > > On Mon, 2011-04-18 at 11:52 -0700, Travis Reitter wrote: > > > > > On Mon, 2011-04-18 at 20:29 +0200, Johannes Schmid wrote: > > > > > > While using GNOME 3.0 on my desktop now for a week I wanted to share my > > > > thoughs on the UI. The problem in the current situation is that the > > > > shell provides a nice chat integration but to start a new chat you have > > > > to use the "Contact List" window of empathy which feels totally > > > > out-of-place. It is also one of the windows you really don't want to see > > > > in the overview. > > > > > > Agreed. I'd like my general chat process to just be: > > > > > > , + > > > > By meta you mean the "windows key" thing? > > > > > which is the same way I launch all my applications in Gnome Shell (and > > > is one of the most compelling features of it, I think). Like launching > > > programs, you would be able to pause to see the full results list and > > > perform more-specific actions (such as selecting the exact account and > > > contact you want to initiate the chat from and to, as Empathy lets you > > > do now). > > > > Yeah, this sounds like about the right thing. I'm thinking we could have > > a new tab in addition to the windows and applications one listing > > people, probably showing the online ones first, or at least making that > > information prominent. Clicking on a person should let you easily send > > mail, start a im conversation or send a file. Additionally these should > > show up on the search results, and be possible to put in the dash. > > > > > > What Daniel and Salamon mocked-up is certainly a nice start but I think > > > > a dedicated window for it doesn't fit with the overall shell design > > > > well. > > > > > > I think it makes sense to have both. The shell search provider would > > > focus on communicating with existing contacts (similar to launching > > > programs), whereas the stand-alone program would be more focused on > > > adding and managing contacts (which are much-rarer actions). And it > > > still makes sense to have the communication buttons in the stand-alone > > > program to make the use case of "add a person, start chat/call with > > > them" smoother than adding them there, then going to the Activities tab > > > to start the communication. > > > > Yeah, I think this is somewhat analogous to the file management > > situation. If you just want to find or open a file you can use the > > shell, but if you want to do more work you'd start the file manager. > > > > So, the gnome-shell integrated part is about day-to-day using of the > > already set up stuff, whereas the contacts app is where you'd fill in > > information, or do more complex stuff like link contacts or create > > groups. > > > > There are other integration points we must think about too. Whatever we > > come up with should imho replace the contacts pane in evolution, and > > must allow interaction with evolution (dnd onto composer windows, etc). > > Also, we should have something that corresponds to clicking on the "to" > > button in the evo compositor to select a single email (or im if used for > > elsewhere) address to add. > > Empathy uses the “text/individual-id” and “text/persona-id” drag targets > for dragging and dropping folks individuals and personas. Shouldn't you be using x-something for nonstandard types like these? Anyway, we'd need to add corresponding support to evolution too. Also, i think the current evolution contacts dialog dnds a vcard, which seems like a good thing to do too. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an underprivileged umbrella-wielding boxer with a passion for fast cars. She's a violent cat-loving advertising executive operating on the wrong side of the law. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
another very important point is synchronisation. together with salomon sickert we thought about how to solve this problem. basically we came up with the idea of a self-replicating backend, like couchdb. if we then could add support to the contact apps of other computer/devices like a n900 or android, we would get synchronisation and conflict management for free. then there is also the idea of having a webservice for the gnome contacts app, where you can access your contacts over the internet. we are very interested in your opinions about this! daniel On Tue, 2011-04-19 at 10:27 +0200, Alexander Larsson wrote: > On Mon, 2011-04-18 at 09:29 -0700, Travis Reitter wrote: > > http://lists.freedesktop.org/archives/telepathy/2011-March/005369.html > > [4] > > This seems to talk about querying contacts from slow social web > services. Additionally if this is to be our story in evolution too we > need to be able to efficiently handle ldap contacts, which are really > important for enterprise deployments of email. This also needs a live > search approach, because we can't rely on a local copy of all ldap data. > -- this mail was sent using 100% recycled electrons daniel g. siegel http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On 19/04/11 10:39, Alexander Larsson wrote: > On Tue, 2011-04-19 at 09:53 +0100, Philip Withnall wrote: >> Empathy uses the “text/individual-id” and “text/persona-id” drag targets >> for dragging and dropping folks individuals and personas. > > Shouldn't you be using x-something for nonstandard types like these? > Anyway, we'd need to add corresponding support to evolution too. Also, i > think the current evolution contacts dialog dnds a vcard, which seems > like a good thing to do too. Pidgin supports dragging and dropping application/x-im-contact and text/x-vcard. Obviously it's unlikely that anyone will ever dnd between Pidgin and Empathy, but it would be nice if Empathy supported these MIME types for interoperability with hypothetical other apps that speak these formats. (Perhaps Evo already understands both? I can't think where else x-im-contact would be used.) Cheers, -- Will ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: > another very important point is synchronisation. together with salomon > sickert we thought about how to solve this problem. basically we came up > with the idea of a self-replicating backend, like couchdb. if we then > could add support to the contact apps of other computer/devices like a > n900 or android, we would get synchronisation and conflict management > for free. > > then there is also the idea of having a webservice for the gnome > contacts app, where you can access your contacts over the internet. > > we are very interested in your opinions about this! I don't know really. Synchronization is a tricky subject, with complex protocols and risk for merge problems. Its almost always a source of weird problems. I don't think we want to have synchronization as some core part of the design. On the other hand, its important that there is some level of support for synchronizing contacts with e.g. phones. So, I guess we need to think about where it fits in. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a shy day-dreaming firefighter who hides his scarred face behind a mask. She's a mistrustful blonde widow with the power to bend men's minds. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On 19 April 2011 11:27, Alexander Larsson wrote: > On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: >> another very important point is synchronisation. together with salomon >> sickert we thought about how to solve this problem. basically we came up >> with the idea of a self-replicating backend, like couchdb. if we then >> could add support to the contact apps of other computer/devices like a >> n900 or android, we would get synchronisation and conflict management >> for free. >> >> then there is also the idea of having a webservice for the gnome >> contacts app, where you can access your contacts over the internet. >> >> we are very interested in your opinions about this! > > I don't know really. Synchronization is a tricky subject, with complex > protocols and risk for merge problems. Its almost always a source of > weird problems. I don't think we want to have synchronization as some > core part of the design. > > On the other hand, its important that there is some level of support for > synchronizing contacts with e.g. phones. So, I guess we need to think > about where it fits in. If you start to talk about synchronisation, please talk to Patrick Ohly . He maintains SyncEvolution that is probably the only working PIM syncing tool that I know of, and it's totally non-trivial. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 11:37 +0100, Ross Burton wrote: > On 19 April 2011 11:27, Alexander Larsson wrote: > > On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: > >> another very important point is synchronisation. together with salomon > >> sickert we thought about how to solve this problem. basically we came up > >> with the idea of a self-replicating backend, like couchdb. if we then > >> could add support to the contact apps of other computer/devices like a > >> n900 or android, we would get synchronisation and conflict management > >> for free. > >> > >> then there is also the idea of having a webservice for the gnome > >> contacts app, where you can access your contacts over the internet. > >> > >> we are very interested in your opinions about this! > > > > I don't know really. Synchronization is a tricky subject, with complex > > protocols and risk for merge problems. Its almost always a source of > > weird problems. I don't think we want to have synchronization as some > > core part of the design. > > > > On the other hand, its important that there is some level of support for > > synchronizing contacts with e.g. phones. So, I guess we need to think > > about where it fits in. > > If you start to talk about synchronisation, please talk to Patrick > Ohly . He maintains SyncEvolution that is > probably the only working PIM syncing tool that I know of, and it's > totally non-trivial. you mean "kinda-working"? ;) indeed, synchronisation with todays devices over syncml is extremely hard. i really don't want that in the core design neither. i was more thinking about a backend like couchdb, which has a synchronisation solution already built in. ubuntu does that for example with evolution and ubuntu one. daniel > > Ross -- this mail was sent using 100% recycled electrons daniel g. siegel http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, Apr 19, 2011 at 11:37:49AM +0100, Ross Burton wrote: > On 19 April 2011 11:27, Alexander Larsson wrote: > > On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: > >> another very important point is synchronisation. together with salomon > >> sickert we thought about how to solve this problem. basically we came up > >> with the idea of a self-replicating backend, like couchdb. if we then > >> could add support to the contact apps of other computer/devices like a > >> n900 or android, we would get synchronisation and conflict management > >> for free. > >> > >> then there is also the idea of having a webservice for the gnome > >> contacts app, where you can access your contacts over the internet. > >> > >> we are very interested in your opinions about this! > > > > I don't know really. Synchronization is a tricky subject, with complex > > protocols and risk for merge problems. Its almost always a source of > > weird problems. I don't think we want to have synchronization as some > > core part of the design. > > > > On the other hand, its important that there is some level of support for > > synchronizing contacts with e.g. phones. So, I guess we need to think > > about where it fits in. > > If you start to talk about synchronisation, please talk to Patrick > Ohly . He maintains SyncEvolution that is > probably the only working PIM syncing tool that I know of, and it's > totally non-trivial. Just recently there were some comment on sad state of sync: http://www.happyassassin.net/2011/04/13/the-continuing-state-of-contact-calendar-synchronization-suck/ http://luther.ceplovi.cz/blog/2011/04/synchronization-sucks/ Can we make synchronisation not suck? -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On 19 April 2011 11:56, Tomasz Torcz wrote: > Just recently there were some comment on sad state of sync: > http://www.happyassassin.net/2011/04/13/the-continuing-state-of-contact-calendar-synchronization-suck/ > http://luther.ceplovi.cz/blog/2011/04/synchronization-sucks/ > > Can we make synchronisation not suck? Patrick actually went to the bother of replying to those posts in blog form: http://syncevolution.org/blogs/pohly/2011/state-syncing-open-source A good read, I recommend it. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On 19/04/11 11:27, Alexander Larsson wrote: > On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: >> another very important point is synchronisation. together with salomon >> sickert we thought about how to solve this problem. basically we came up >> with the idea of a self-replicating backend, like couchdb. if we then >> could add support to the contact apps of other computer/devices like a >> n900 or android, we would get synchronisation and conflict management >> for free. >> >> then there is also the idea of having a webservice for the gnome >> contacts app, where you can access your contacts over the internet. >> >> we are very interested in your opinions about this! > > I don't know really. Synchronization is a tricky subject, with complex > protocols and risk for merge problems. Its almost always a source of > weird problems. I don't think we want to have synchronization as some > core part of the design. > > On the other hand, its important that there is some level of support for > synchronizing contacts with e.g. phones. So, I guess we need to think > about where it fits in. > Hmm, its really not that tricky - the eventually consistent method used by couch works well in most situations - all replicated endpoints resolve to the same state without intervention, and if you want to pick up any pieces, you can. I would be happy to help out any team forming to look at the area - at work we've had a few people building replicating (mobile/server) apps with couchdb and it's a very nice system. Also, semi-schema'd document based storage like couch works nicely for extensibility and data mashups. On supporting existing sync protocols, for 'traditional' sync, its important to have one central point of resolution, and that's ideally a server. A nice plan would be a server side component (on gnome.org of course) that has an activesync and syncml endpoint which syncs into a couchdb database for replication with the desktop. For activesync, z-push [1] works well, and can be made pretty scalable with a few changes. for SyncML, there's good open source components like funambol [2] available. I'd probably be able to swing some sponsorship for hosted servers if we can put together a team looking at this. Rob [1] http://z-push.sourceforge.net/soswp/ [2] https://www.forge.funambol.org/DomainHome.html -- Rob Taylor, CTO, Codethink Ltd. - http://codethink.co.uk Twitter: @robtaylor78 - LinkedIn: http://www.linkedin.com/in/robtaylor78 Office: +44 161 236 5575 - Cell: +44 7891 533856 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
> Can we make synchronisation not suck? > Achieving good and non-breaking sync is really hard and sometimes next to impossible, given that the formats used in PIM sync (vCard, I'm looking at you) are really weird and broadly interpreted differently by different devices out there (Like e.g. the intepretation of the FN field) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
and right here i think we shouldn't base on bad formats (vcard) and sucking protocols (syncml). using json is a much better option. see for example the desktopcouch specification for contacts http://www.freedesktop.org/wiki/Specifications/desktopcouch/contact On Tue, 2011-04-19 at 14:11 +0300, Jens Georg wrote: > > Can we make synchronisation not suck? > > > Achieving good and non-breaking sync is really hard and sometimes next > to impossible, given that the formats used in PIM sync (vCard, I'm > looking at you) are really weird and broadly interpreted differently by > different devices out there (Like e.g. the intepretation of the FN > field) > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 12:41 +0200, daniel g. siegel wrote: > On Tue, 2011-04-19 at 11:37 +0100, Ross Burton wrote: > > On 19 April 2011 11:27, Alexander Larsson wrote: > > > On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: > > >> another very important point is synchronisation. together with salomon > > >> sickert we thought about how to solve this problem. basically we came up > > >> with the idea of a self-replicating backend, like couchdb. if we then > > >> could add support to the contact apps of other computer/devices like a > > >> n900 or android, we would get synchronisation and conflict management > > >> for free. > > >> > > >> then there is also the idea of having a webservice for the gnome > > >> contacts app, where you can access your contacts over the internet. > > >> > > >> we are very interested in your opinions about this! > > > > > > I don't know really. Synchronization is a tricky subject, with complex > > > protocols and risk for merge problems. Its almost always a source of > > > weird problems. I don't think we want to have synchronization as some > > > core part of the design. > > > > > > On the other hand, its important that there is some level of support for > > > synchronizing contacts with e.g. phones. So, I guess we need to think > > > about where it fits in. > > > > If you start to talk about synchronisation, please talk to Patrick > > Ohly . He maintains SyncEvolution that is > > probably the only working PIM syncing tool that I know of, and it's > > totally non-trivial. > > you mean "kinda-working"? ;) indeed, synchronisation with todays devices > over syncml is extremely hard. i really don't want that in the core > design neither. > > i was more thinking about a backend like couchdb, which has a > synchronisation solution already built in. ubuntu does that for example > with evolution and ubuntu one. > evolution-couchdb provides that already, so if folks has an e-d-s backend, it should already be available. Also, replication/conflict management in couchdb is quite good indeed The "problem" with this is that for couchdb to be really useful, the best thing is to run a local instance that then syncs to a remote instance, and while it's entirely possible (as you said, Ubuntu One does it) some people showed their concerns when I proposed couchdb-glib/evolution-couchdb (for 2.30 I think it was) about running a local instance of couchdb. But yes, should be perfectly possible. Maybe we should revisit the discussion again? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 13:21 +0200, Rodrigo Moya wrote: > On Tue, 2011-04-19 at 12:41 +0200, daniel g. siegel wrote: > > On Tue, 2011-04-19 at 11:37 +0100, Ross Burton wrote: > > > On 19 April 2011 11:27, Alexander Larsson wrote: > > > > On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: > > > >> another very important point is synchronisation. together with salomon > > > >> sickert we thought about how to solve this problem. basically we came > > > >> up > > > >> with the idea of a self-replicating backend, like couchdb. if we then > > > >> could add support to the contact apps of other computer/devices like a > > > >> n900 or android, we would get synchronisation and conflict management > > > >> for free. > > > >> > > > >> then there is also the idea of having a webservice for the gnome > > > >> contacts app, where you can access your contacts over the internet. > > > >> > > > >> we are very interested in your opinions about this! > > > > > > > > I don't know really. Synchronization is a tricky subject, with complex > > > > protocols and risk for merge problems. Its almost always a source of > > > > weird problems. I don't think we want to have synchronization as some > > > > core part of the design. > > > > > > > > On the other hand, its important that there is some level of support for > > > > synchronizing contacts with e.g. phones. So, I guess we need to think > > > > about where it fits in. > > > > > > If you start to talk about synchronisation, please talk to Patrick > > > Ohly . He maintains SyncEvolution that is > > > probably the only working PIM syncing tool that I know of, and it's > > > totally non-trivial. > > > > you mean "kinda-working"? ;) indeed, synchronisation with todays devices > > over syncml is extremely hard. i really don't want that in the core > > design neither. > > > > i was more thinking about a backend like couchdb, which has a > > synchronisation solution already built in. ubuntu does that for example > > with evolution and ubuntu one. > > > evolution-couchdb provides that already, so if folks has an e-d-s > backend, it should already be available. Also, replication/conflict > management in couchdb is quite good indeed > > The "problem" with this is that for couchdb to be really useful, the > best thing is to run a local instance that then syncs to a remote > instance, and while it's entirely possible (as you said, Ubuntu One does > it) some people showed their concerns when I proposed > couchdb-glib/evolution-couchdb (for 2.30 I think it was) about running a > local instance of couchdb. > > But yes, should be perfectly possible. Maybe we should revisit the > discussion again? > imho couchdb is just one way of many, but certainyl the right direction. you guys showed, that it is possible to have a working synchronisation quite easily with couchdb. so yes, let's re-evaluate possible backends? -- this mail was sent using 100% recycled electrons daniel g. siegel http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 13:21 +0200, daniel g. siegel wrote: > and right here i think we shouldn't base on bad formats (vcard) and > sucking protocols (syncml). using json is a much better option. Well as soon as you talk about sync, someone says device. And devices come with vCard. > see for example the desktopcouch specification for contacts > http://www.freedesktop.org/wiki/Specifications/desktopcouch/contact Looking at this - do you realise how much very much that matches the vCard spec? That's basically a vCard translated to JSON. Personally, I'd rather have a root canal treatment than couch db hammering my computer, but I like the auto-replication idea. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Mon, 2011-04-18 at 09:29 -0700, Travis Reitter wrote: > As Frederic pointed out, we shouldn't be brainstorming on the 3.2 > feature pages, so I thought I'd fill in some details/thoughts on the > Contacts [1] idea here. > > The page suggests libfolks and/or libsocialweb for the implementation. > The good news is that Folks 0.5.0 (released last week) added support for > libsocialweb, so using Folks gets you both. In the process, Alban Crequy > also added Contacts support for a few libsocialweb services in > libsocialweb itself (Flickr, Twitter, Last.FM) and upstreamed Marco > Barisione's Facebook support. The remaining lsw services (such as Vimeo > and YouTube) don't have Contacts support yet, but it could certainly be > added. > this makes a lot of sense, but we really need a way to send messages to facebook/twitter contacts, or do other operations on the other services (see photos from flickr, listen to music in last.fm, etc). So, are there any plans for a twitter/facebook client app? For photos and music, I guess it's easy, since we can't just start the corresponding app/url from the 'contacts view' in the shell ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 14:38 +0300, Jens Georg wrote: > On Tue, 2011-04-19 at 13:21 +0200, daniel g. siegel wrote: > > and right here i think we shouldn't base on bad formats (vcard) and > > sucking protocols (syncml). using json is a much better option. > > Well as soon as you talk about sync, someone says device. And devices > come with vCard. there is no problem in providing an import function for vcards > > > see for example the desktopcouch specification for contacts > > http://www.freedesktop.org/wiki/Specifications/desktopcouch/contact > > Looking at this - do you realise how much very much that matches the > vCard spec? That's basically a vCard translated to JSON. > > Personally, I'd rather have a root canal treatment than couch db > hammering my computer, but I like the auto-replication idea. you are right. but i just wanted to show this as an example. personally i am not totally happy with the specification, as there are for example legacy items, like pager and others. but it is a good start. > -- this mail was sent using 100% recycled electrons daniel g. siegel http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 13:28 +0200, daniel g. siegel wrote: > On Tue, 2011-04-19 at 13:21 +0200, Rodrigo Moya wrote: > > On Tue, 2011-04-19 at 12:41 +0200, daniel g. siegel wrote: > > > On Tue, 2011-04-19 at 11:37 +0100, Ross Burton wrote: > > > > On 19 April 2011 11:27, Alexander Larsson wrote: > > > > > On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: > > > > >> another very important point is synchronisation. together with > > > > >> salomon > > > > >> sickert we thought about how to solve this problem. basically we > > > > >> came up > > > > >> with the idea of a self-replicating backend, like couchdb. if we then > > > > >> could add support to the contact apps of other computer/devices like > > > > >> a > > > > >> n900 or android, we would get synchronisation and conflict management > > > > >> for free. > > > > >> > > > > >> then there is also the idea of having a webservice for the gnome > > > > >> contacts app, where you can access your contacts over the internet. > > > > >> > > > > >> we are very interested in your opinions about this! > > > > > > > > > > I don't know really. Synchronization is a tricky subject, with complex > > > > > protocols and risk for merge problems. Its almost always a source of > > > > > weird problems. I don't think we want to have synchronization as some > > > > > core part of the design. > > > > > > > > > > On the other hand, its important that there is some level of support > > > > > for > > > > > synchronizing contacts with e.g. phones. So, I guess we need to think > > > > > about where it fits in. > > > > > > > > If you start to talk about synchronisation, please talk to Patrick > > > > Ohly . He maintains SyncEvolution that is > > > > probably the only working PIM syncing tool that I know of, and it's > > > > totally non-trivial. > > > > > > you mean "kinda-working"? ;) indeed, synchronisation with todays devices > > > over syncml is extremely hard. i really don't want that in the core > > > design neither. > > > > > > i was more thinking about a backend like couchdb, which has a > > > synchronisation solution already built in. ubuntu does that for example > > > with evolution and ubuntu one. > > > > > evolution-couchdb provides that already, so if folks has an e-d-s > > backend, it should already be available. Also, replication/conflict > > management in couchdb is quite good indeed > > > > The "problem" with this is that for couchdb to be really useful, the > > best thing is to run a local instance that then syncs to a remote > > instance, and while it's entirely possible (as you said, Ubuntu One does > > it) some people showed their concerns when I proposed > > couchdb-glib/evolution-couchdb (for 2.30 I think it was) about running a > > local instance of couchdb. > > > > But yes, should be perfectly possible. Maybe we should revisit the > > discussion again? > > > > imho couchdb is just one way of many, but certainyl the right direction. > you guys showed, that it is possible to have a working synchronisation > quite easily with couchdb. so yes, let's re-evaluate possible backends? > what do you mean by 'backends'? Backends of what? As I said, evolution-couchdb already provides an e-d-s backend for accessing contacts in CouchDB databases, so IMO, what we need is: * a user service that starts a local couchdb instance * a way for evo-couchdb to know at what port that instance is listening (if it's random, maybe we could establish a standard one). With desktopcouch (the Ubuntu One local couchdb instance), we do a DBus call to obtain the port, but that's quite tricky, as couchdb can crash and thus start on a different port. Another option would be to provide a full DBus service that allows access to that local instance, regardless of the port, but then we'll need to write lots of new code to talk to that service, as evolution-couchdb just talks the CouchDB protocol (http://wiki.apache.org/couchdb/Reference) which works for any couchdb instance, whether it's local or remote. * a tool to configure where to replicate the local instance to * authentication for the local and remote instances. couchdb-glib (the API implementing the couchdb client-side protocol) already supports OAuth and user/password authentication ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 14:38 +0300, Jens Georg wrote: > On Tue, 2011-04-19 at 13:21 +0200, daniel g. siegel wrote: > > and right here i think we shouldn't base on bad formats (vcard) and > > sucking protocols (syncml). using json is a much better option. > > Well as soon as you talk about sync, someone says device. And devices > come with vCard. > > > see for example the desktopcouch specification for contacts > > http://www.freedesktop.org/wiki/Specifications/desktopcouch/contact > > Looking at this - do you realise how much very much that matches the > vCard spec? That's basically a vCard translated to JSON. > well, that's because the fields used to describe a contact are quite obvious, so it's not a vcard->json translation really, it's just a set of fields to describe a contact, which happen to be also in vCard > Personally, I'd rather have a root canal treatment than couch db > hammering my computer, but I like the auto-replication idea. > auto-replication of several instances and, most important, conflict management for free :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
> what do you mean by 'backends'? Backends of what? As I said, > evolution-couchdb already provides an e-d-s backend for accessing > contacts in CouchDB databases, so IMO, what we need is: so my question is basically: why do we need e-d-s if we have our contacts in couchdb? -- this mail was sent using 100% recycled electrons daniel g. siegel http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
libfolks was explicitly designed to aggregate contact information instead of synchronising it, entirely because synchronisation is hard. Philip On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: > another very important point is synchronisation. together with salomon > sickert we thought about how to solve this problem. basically we came up > with the idea of a self-replicating backend, like couchdb. if we then > could add support to the contact apps of other computer/devices like a > n900 or android, we would get synchronisation and conflict management > for free. > > then there is also the idea of having a webservice for the gnome > contacts app, where you can access your contacts over the internet. > > we are very interested in your opinions about this! > > daniel > > On Tue, 2011-04-19 at 10:27 +0200, Alexander Larsson wrote: > > On Mon, 2011-04-18 at 09:29 -0700, Travis Reitter wrote: > > > http://lists.freedesktop.org/archives/telepathy/2011-March/005369.html > > > [4] > > > > This seems to talk about querying contacts from slow social web > > services. Additionally if this is to be our story in evolution too we > > need to be able to efficiently handle ldap contacts, which are really > > important for enterprise deployments of email. This also needs a live > > search approach, because we can't rely on a local copy of all ldap data. > > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, Apr 19, 2011 at 02:14:41PM +0200, daniel g. siegel wrote: > so my question is basically: why do we need e-d-s if we have our > contacts in couchdb? Don't forget features have to be across the whole of GNOME core. Cannot ignore e-d-s if that results in an incomplete user experience (some parts using one technology, some parts another). -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
Hello! Rob Taylor codethink.co.uk> writes: > On 19/04/11 11:27, Alexander Larsson wrote: > > On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: Ross pointed me to this discussion. Let me jump into the discussion by replying to a more or less random post and quoting some other relevant statements. I'm not subscribed, so please CC me. For some background on why sync is hard, here's an article that I wrote a while ago for LWN.net: http://syncevolution.org/development/pim-data-synchronization-why-it-so-hard Note that this applies to both contacts and calendar, and probably more. If you design something new for GNOME, please don't focus exclusively on contacts. > >> another very important point is synchronisation. together with salomon > >> sickert we thought about how to solve this problem. basically we came up > >> with the idea of a self-replicating backend, like couchdb. That only gives you a closed solution between peers which share that self-replicating data. If you model it after couchdb (or just stick with couchdb), then a unique ID is assigned to each new contact once, when it gets created, and thus there's never any confusion whether a peer already has some data. > >> if we then > >> could add support to the contact apps of other computer/devices like a > >> n900 or android, we would get synchronisation and conflict management > >> for free. Nothing will be for free once you want to add interoperability :-/ All of the challenges mentioned in the article above will still apply (no unique ID in those peers, legacy formats, different data models). > >> then there is also the idea of having a webservice for the gnome > >> contacts app, where you can access your contacts over the internet. > >> > >> we are very interested in your opinions about this! > > > > I don't know really. Synchronization is a tricky subject, with complex > > protocols and risk for merge problems. Its almost always a source of > > weird problems. I don't think we want to have synchronization as some > > core part of the design. > > > > On the other hand, its important that there is some level of support for > > synchronizing contacts with e.g. phones. So, I guess we need to think > > about where it fits in. If I had one wish, then it is this one: ensure that each item gets a unique, vendor created ID that never changes throughout the lifetime of the item. Currently EDS supports that for calendar (part of iCalendar 2.0 semantic), but not in the file contact backend (not required by vCard 3.0). Any UID that might have been set in a new vCard is overwritten by a local ID. > Hmm, its really not that tricky - the eventually consistent method used > by couch works well in most situations - all replicated endpoints > resolve to the same state without intervention, and if you want to pick > up any pieces, you can. For couchdb<->couchdb sync, yes, but that's only a subset of the problem - unless you can convince the rest of the world to use the same system. Start by convincing the Tracker/Ontology proponents, who also want everyone else to use their system for data replication ;-) I'm pragmatic and don't expect that any system will ever take over enough to use it exclusively. Regarding couchdb: how complete is its data model? When it first showed up, SyncEvolution had some problems with it because REV wasn't supported, if memory serves me right. > On supporting existing sync protocols, for 'traditional' sync, its > important to have one central point of resolution, and that's ideally a > server. Then the server becomes easily the weakest link in the chain. In the past, dumb phones had a very limited data model that could be completely supported by a (SyncML) server. Nowadays the address book in a client is very rich and may contain data that is not supported by many servers - that's definitely the case with, for example, MeeGo to Google sync. If the client then trusts the server exclusively to resolve conflicts, data is lost on the server. Another conceptual problem is that the server cannot communicate well with the user. A client might pop up rich dialogs and ask the user for help in cases that it cannot decide automatically (but designing such a dialog is an unsolved problem). SyncML servers (and probably other servers, too) don't have that option and instead fall back to heuristics which fail inevitably in some cases. > A nice plan would be a server side component (on gnome.org of > course) that has an activesync and syncml endpoint which syncs into a > couchdb database for replication with the desktop. For activesync, > z-push [1] works well, and can be made pretty scalable with a few > changes. for SyncML, there's good open source components like funambol > [2] available. I personally would rather recommend the Synthesis engine instead of Funambol. Much more light-weight and miles ahead Funambol regarding SyncML support and data merging (for example, supports suspend/resume and much smarter conflict res
Online Accounts panel for 3.2
Hey, One of the things I'm looking at doing for 3.2 is the Web Accounts panel: http://live.gnome.org/ThreePointOne/Features/Sharing http://live.gnome.org/Design/SystemSettings/Profile I sat down last week with one of the designers, Jon McCann, and we came up with what we both think is a really nice user experience. It is described in [1] for now - will move to the wiki soon. Implementation-wise, I can see this as a very minimal daemon / library that sits below libsocialweb, Telepathy, e-d-s and other APIs (e.g. these libraries/frameworks would use this new framework) that is dealing data online accounts. This daemon / library would a. have a notion of "source types" - email source - calendar source - chat source - photos source - contacts source - ... b. have a notion of providers that can be added removed by the end user - Google (for accounts at google.com and Apps For Your Domain) - Yahoo/Flickr - Exchange - Facebook - ... c. provide a concrete list of providers and what sources the instance of the provider supports. For example, for my setup, I would have the following - zeut...@gmail.com (an instance of the Google data provider) - Mail (email source) - Contacts (contacts source) - Calendar (calendar source) - Chat (chat source) - da...@fubar.dk (an instance of the Google data provider) - (works because fubar.dk is using Google Apps For Your Domain) - Mail (email source) - dzeut...@yahoo.com (an instance of the Yahoo! data provider) - Flickr! (photos source) - (I specifically unchecked mail here because I don't want the spam that is in that email account that I never use) - davidz25 (an instance of the Facebook data provider) - Messages (email source) - Events (calendar source) The information in c. would map exactly to what the "Web Accounts" UI would display: +--+ | All Settings | +--+ | +---+ Google Account| | | [Go] zeut...@gmail.com|| | | [Go] da...@fubar.dk (!) | Username: david | | | [Y!] dzeut...@yahoo.com | Domain: fubar.dk_ | | | [Fb] davidz25 || | | | Use this account for: | | | || | | | [ON ] Mail | | | | [ OFF] Chat | | | | [ OFF] Contacts | | | | [ OFF] Calendar | | | || | +---+ (!) Authorization expired. | | | [+] [-] | Please login again.| | +---+[Login] | +--+ This "screenshot" shows an example where the da...@fubar.dk account needs attention (suppose that the password has been changed from another system). In this case, I think the desktop would show the user a notification saying "The account da...@fubar.dk needs your attention" and upon clicking on it, the user is taking to the control-center pane above. This daemon/library thing, let's call it GOA (Gnome Online Accounts), would _not_ be a mechanism to access any of these services. But it would provide e.g. libsocialweb, telepathy, e-d-s and so on with either the username/password combo or the OAuth token, whatever is appropriate. I would imagine Telepathy/Empathy to use GOA to get the Chat accounts that is configured in GOA (in the above example, it would be Google Talk from zeut...@gmail.com and Facebook Chat for davidz25). I would use an Empathy specific preferences window (not appearing in gnome-control-center I think) to add e.g. my ICQ account. There are of course security / implementation considerations (password/auth token hygiene, should we treat the desktop like it's not a single security context when it really is?) here - all of that comes next. Technically, I'm proposing that we add a GOA module with - a daemon, goad, that implements the org.gnome.OnlineAccounts interface on a well-known object /org/gnome/OnlineAccounts and owns the well-known name org.gnome.OnlineAccounts (all this is on the session bus). Additionally, this daemon would notify the user if attention is needed (e.g. reauth) using org.freedesktop.Notificatins / libnotify. - a library, libgoa-1.0, that is used to speak to goad (but an app can also just use the D-Bus interface if it wants to). This library is what
Re: Online Accounts panel for 3.2
On Tue, 2011-04-19 at 09:08 -0400, David Zeuthen wrote: > This daemon/library thing, let's call it GOA (Gnome Online Accounts), > would _not_ be a mechanism to access any of these services. But it > would provide e.g. libsocialweb, telepathy, e-d-s and so on with > either the username/password combo or the OAuth token, whatever is > appropriate. The hard part here is handling application-authorisation. For example, for Flickr, it's not enough to have a login/password combo, you also need to allow the framework/application access to the account. You'll also see that both libsocialweb and bisho (the "config panel" for libsocialweb) have quite a lot of that code, including oauth helpers. It would certainly make sense to split it out of libsocialweb in this case. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Le mardi 19 avril 2011 à 09:08 -0400, David Zeuthen a écrit : > - a daemon, goad, that implements the org.gnome.OnlineAccounts > interface >on a well-known object /org/gnome/OnlineAccounts and owns the > well-known >name org.gnome.OnlineAccounts (all this is on the session bus). > >Additionally, this daemon would notify the user if attention is >needed (e.g. reauth) using org.freedesktop.Notificatins / > libnotify. Do you really need a daemon? Sounds like everything could be handled by applications that use these accounts via the library. Is there a point in connecting to these accounts if no app is using them? If not, then notifications can be emitted by the app when it tries to connect and finds the password has changed (which would be done automatically by libgoa). And the library would get information about accounts from GSettings and gnome-keyring, without the need for any daemon. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hi David, On 04/19/2011 04:08 PM, David Zeuthen wrote: Hey, One of the things I'm looking at doing for 3.2 is the Web Accounts panel: http://live.gnome.org/ThreePointOne/Features/Sharing See the "Current status" section in that page. We already have all of this (and more) in MeeGo, and I'm willing to support any efforts in bringing this to Gnome. I sat down last week with one of the designers, Jon McCann, and we came up with what we both think is a really nice user experience. It is described in [1] for now - will move to the wiki soon. Implementation-wise, I can see this as a very minimal daemon / library that sits below libsocialweb, Telepathy, e-d-s and other APIs (e.g. these libraries/frameworks would use this new framework) that is dealing data online accounts. In MeeGo we chose two split the thing into two: account framework, which simply consists of descriptions of providers and sources (which we call "services"), and a library wrapping a SQLite DB for accounts settings, where applications can read/store accounts settings (not the passwords). The provider and services are described by XML files, which can be installed in predefined directories. This allows for expandability: to support a new service, you just need to install a package which adds a service XML file. The service XML files not only describe the service (icon, name and provider) but also contain a default value for account settings; the account library uses these settings as fallback when a settings has not been explicitly written in the DB -- this is all transparent to the application. The point of this is that you don't want to ask the user for the address of the IMAP server of GMail: we can write it in the service XML file. The accounts library support change notification via D-Bus, so that when a setting in the GMail account has been modified, all applications interested in the e-mail service type are notified and can reconnect the account. This daemon / library would a. have a notion of "source types" - email source [...] b. have a notion of providers that can be added removed by the end user - Google (for accounts at google.com and Apps For Your Domain) [...] c. provide a concrete list of providers and what sources the instance of the provider supports. For example, for my setup, I would have the following - zeut...@gmail.com (an instance of the Google data provider) - Mail (email source) - Contacts (contacts source) - Calendar (calendar source) - Chat (chat source) [...] It's similar to what we have, except that we don't hardcode the list of available sources in the provider file. It's the source, who tells what provider (and source-type) it belongs to. This "screenshot" shows an example where the da...@fubar.dk account needs attention (suppose that the password has been changed from another system). In this case, I think the desktop would show the user a notification saying "The account da...@fubar.dk needs your attention" and upon clicking on it, the user is taking to the control-center pane above. Mmm... that's one option, though I'd rather like that by clicking on the notification you directly go to the login screen where you can enter your password. And one thing that I heartily recommend you based on experience: do *never* let the user change the username once the account has been created. This saves you a lot of trouble. This daemon/library thing, let's call it GOA (Gnome Online Accounts), would _not_ be a mechanism to access any of these services. But it would provide e.g. libsocialweb, telepathy, e-d-s and so on with either the username/password combo or the OAuth token, whatever is appropriate. And for this we have the SSO framework in MeeGo. It's one daemon, that stores the user credentials on an encrypted partition which is mounted only when the user is identified (in our device we'll use the SIM card for this goal, in the Gnome desktop it could be the lock-screen password). Passwords are generally not given back to applications; instead, signond (the SSO daemon) loads a plugin specific to the authentication method being used (SASL, OAuth, Google, etc.): the plugin gets the passwords, and uses it to compute a response to give back to the client. This response can be a response that the client must give back to the remote server in a SASL challenge, or a token that can be used to login. In cases where the authentication plugin performs the authentication with the remote server, in case the password is wrong it will itself inform signond, which in turn will invoke a UI to prompt the user for a new password. If instead the plugin is simply computing responses without having knowledge if the password is correct, the application will get an error and it can retry the authentication with a flag which tells signond to ask the user for a new password before computing the response. I would ima
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 14:14 +0200, daniel g. siegel wrote: > > what do you mean by 'backends'? Backends of what? As I said, > > evolution-couchdb already provides an e-d-s backend for accessing > > contacts in CouchDB databases, so IMO, what we need is: > > so my question is basically: why do we need e-d-s if we have our > contacts in couchdb? > ah ok, I see what you mean. We need e-d-s for Evolution to access the contacts, and if libfolks already has an e-d-s backend, it will get contacts for every addressbook configured in Evolution, right? If not, yes, just using couchdb-glib directly in whatever 'backend' you want works. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On 19/04/11 13:45, Patrick Ohly wrote: > Hello! > > Rob Taylor codethink.co.uk> writes: >> On 19/04/11 11:27, Alexander Larsson wrote: >>> On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: > > Ross pointed me to this discussion. Let me jump into the discussion by > replying to a more or less random post and quoting some other relevant > statements. I'm not subscribed, so please CC me. > > For some background on why sync is hard, here's an article that I > wrote a while ago for LWN.net: > http://syncevolution.org/development/pim-data-synchronization-why-it-so-hard > > Note that this applies to both contacts and calendar, and probably > more. If you design something new for GNOME, please don't focus > exclusively on contacts. > another very important point is synchronisation. together with salomon sickert we thought about how to solve this problem. basically we came up with the idea of a self-replicating backend, like couchdb. > > That only gives you a closed solution between peers which share that > self-replicating data. If you model it after couchdb (or just stick > with couchdb), then a unique ID is assigned to each new contact once, > when it gets created, and thus there's never any confusion whether a > peer already has some data. > if we then could add support to the contact apps of other computer/devices like a n900 or android, we would get synchronisation and conflict management for free. > > Nothing will be for free once you want to add interoperability :-/ All > of the challenges mentioned in the article above will still apply (no > unique ID in those peers, legacy formats, different data models). > then there is also the idea of having a webservice for the gnome contacts app, where you can access your contacts over the internet. we are very interested in your opinions about this! >>> >>> I don't know really. Synchronization is a tricky subject, with complex >>> protocols and risk for merge problems. Its almost always a source of >>> weird problems. I don't think we want to have synchronization as some >>> core part of the design. >>> >>> On the other hand, its important that there is some level of support for >>> synchronizing contacts with e.g. phones. So, I guess we need to think >>> about where it fits in. > > If I had one wish, then it is this one: ensure that each item gets a > unique, vendor created ID that never changes throughout the lifetime > of the item. > > Currently EDS supports that for calendar (part of iCalendar 2.0 > semantic), but not in the file contact backend (not required by vCard > 3.0). Any UID that might have been set in a new vCard is overwritten > by a local ID. > >> Hmm, its really not that tricky - the eventually consistent method used >> by couch works well in most situations - all replicated endpoints >> resolve to the same state without intervention, and if you want to pick >> up any pieces, you can. > > For couchdb<->couchdb sync, yes, but that's only a subset of the > problem - unless you can convince the rest of the world to use the > same system. Start by convincing the Tracker/Ontology proponents, who > also want everyone else to use their system for data replication ;-) > > I'm pragmatic and don't expect that any system will ever take over > enough to use it exclusively. > > Regarding couchdb: how complete is its data model? When it first > showed up, SyncEvolution had some problems with it because REV wasn't > supported, if memory serves me right. Since 1.0 it's been pretty sweet, with all the functionality working well - including live updates. >> On supporting existing sync protocols, for 'traditional' sync, its >> important to have one central point of resolution, and that's ideally a >> server. > > Then the server becomes easily the weakest link in the chain. In the > past, dumb phones had a very limited data model that could be > completely supported by a (SyncML) server. Nowadays the address book > in a client is very rich and may contain data that is not supported by > many servers - that's definitely the case with, for example, MeeGo to > Google sync. > > If the client then trusts the server exclusively to resolve conflicts, > data is lost on the server. Hmm, the actual problem here is not the server - its the representation format. I would argue that the correct approach to this is to always represent all the data you receive from clients - and transform the stuff you do understand in to a common representation. > Another conceptual problem is that the server cannot communicate well > with the user. A client might pop up rich dialogs and ask the user for > help in cases that it cannot decide automatically (but designing such > a dialog is an unsolved problem). SyncML servers (and probably other > servers, too) don't have that option and instead fall back to > heuristics which fail inevitably in some cases. Think of couch as a bit like git - you never resolve on t
Re: Online Accounts panel for 3.2
Hi, On Tue, Apr 19, 2011 at 9:28 AM, Bastien Nocera wrote: > On Tue, 2011-04-19 at 09:08 -0400, David Zeuthen wrote: > >> This daemon/library thing, let's call it GOA (Gnome Online Accounts), >> would _not_ be a mechanism to access any of these services. But it >> would provide e.g. libsocialweb, telepathy, e-d-s and so on with >> either the username/password combo or the OAuth token, whatever is >> appropriate. > > The hard part here is handling application-authorisation. For example, > for Flickr, it's not enough to have a login/password combo, you also > need to allow the framework/application access to the account. > > You'll also see that both libsocialweb and bisho (the "config panel" for > libsocialweb) have quite a lot of that code, including oauth helpers. It > would certainly make sense to split it out of libsocialweb in this case. Yup, I most of that out of my initial description to keep it short (I tried to allude that both authorization (authorize app to use flickr) and authentication (proving to flickr who you are) might need a web browser in the footnote) - would definitely not want to rewrite all that code if it's already written. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
On Tue, Apr 19, 2011 at 10:23 AM, David Zeuthen wrote: > Yup, I most of that out of my initial description to keep it short Sorry, I obviously haven't had enough coffee yet - I meant to say that I left authorization and authentication details out of my initial description to keep it short. > (I tried to allude that both authorization (authorize app to use flickr) > and authentication (proving to flickr who you are) might need a web > browser in the footnote) - would definitely not want to rewrite all > that code if it's already written. > > David > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
On Tue, Apr 19, 2011 at 9:57 AM, Milan Bouchet-Valat wrote: > Le mardi 19 avril 2011 à 09:08 -0400, David Zeuthen a écrit : >> - a daemon, goad, that implements the org.gnome.OnlineAccounts >> interface >> on a well-known object /org/gnome/OnlineAccounts and owns the >> well-known >> name org.gnome.OnlineAccounts (all this is on the session bus). >> >> Additionally, this daemon would notify the user if attention is >> needed (e.g. reauth) using org.freedesktop.Notificatins / >> libnotify. > Do you really need a daemon? Sounds like everything could be handled by > applications that use these accounts via the library. Is there a point > in connecting to these accounts if no app is using them? > > If not, then notifications can be emitted by the app when it tries to > connect and finds the password has changed (which would be done > automatically by libgoa). And the library would get information about > accounts from GSettings and gnome-keyring, without the need for any > daemon. It's not unimaginable that some online service might want to use some 3rd party library to do its thing. It's also just a lot simpler to serialize writes etc. if you know that only one process is going to touch the data at any one time. Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hi! > And for this we have the SSO framework in MeeGo. It's one daemon, that stores > the user credentials on an encrypted partition which is mounted only when the > user is identified (in our device we'll use the SIM card for this goal, in > the > Gnome desktop it could be the lock-screen password). We have (most of) that already, it's gnome-keyring/seahorse. What we need is a way to give back no the password but some kind of connection object (if we want that). Regards, Johannes signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 12:45 +, Patrick Ohly wrote: > > Regarding couchdb: how complete is its data model? When it first > showed up, SyncEvolution had some problems with it because REV wasn't > supported, if memory serves me right. > IIRC, that was a bug you filed for evolution-couchdb, which didn't include the REV field, which I fixed some months ago. As for couchdb, each document has a unique, cross-database revision number ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hey Alberto, Thanks for your response! On Tue, Apr 19, 2011 at 10:12 AM, Alberto Mardegan wrote: > Hi David, > > On 04/19/2011 04:08 PM, David Zeuthen wrote: >> >> Hey, >> >> One of the things I'm looking at doing for 3.2 is the Web Accounts panel: >> >> http://live.gnome.org/ThreePointOne/Features/Sharing > > See the "Current status" section in that page. We already have all of this > (and more) in MeeGo, and I'm willing to support any efforts in bringing this > to Gnome. I did briefly look at http://gitorious.org/accounts-sso/accounts-glib but quickly got lost as that appears to be just the client-side GLib glue. And some of the other stuff looked pretty specific to Meego. >> There are of course security / implementation considerations >> (password/auth token hygiene, should we treat the desktop like it's >> not a single security context when it really is?) here - all of that >> comes next. > > We addressed all security concerns already; feel free to ask in case you > have some doubts. Oh, it's not so much that I had any unresolved concerns - I was just pointing out that I was aware that I knew that I have to be careful there. > I'm sure that especially for the SSO part there'll be need for work in order > to adapt it to the desktop; but it will still be far quicker than rewriting > everything. The accounts part should be already well working on the desktop. Can you give a short overview of exactly what components that you've written that GNOME would use (including their dependencies and whether it's a per-session daemon, per-system daemon or shared library), what GNOME would need to write itself and how it would fit together with the UX that I've described? I mean, obviously accounts-glib would be an external dep and obviously we'd write our own GNOME Control Center panel ... but what else? I'm asking mostly to figure out what additional dependencies this would add to GNOME if we were to use it! Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
David Zeuthen wrote: > I would imagine Telepathy/Empathy to use GOA to get the Chat accounts > that is configured in GOA (in the above example, it would be Google > Talk from zeut...@gmail.com and Facebook Chat for davidz25). I would > use an Empathy specific preferences window (not appearing in > gnome-control-center I think) to add e.g. my ICQ account. Could you elaborate on this, e.g. why would ICQ and other types of online accounts be deported to a specific preferences window? This is somehow related to the "Contacts" thread, where it is said we could replace the empathy contact list with the shell; in this scheme there's no place any longer for that specific preferences window, and it makes sense (to me) to have it in the online accounts panel, along others. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Control Center items (Was Re: Online Accounts panel for 3.2)
Hi, On Tue, Apr 19, 2011 at 10:52 AM, Frederic Peters wrote: > David Zeuthen wrote: > >> I would imagine Telepathy/Empathy to use GOA to get the Chat accounts >> that is configured in GOA (in the above example, it would be Google >> Talk from zeut...@gmail.com and Facebook Chat for davidz25). I would >> use an Empathy specific preferences window (not appearing in >> gnome-control-center I think) to add e.g. my ICQ account. > > Could you elaborate on this, e.g. why would ICQ and other types of > online accounts be deported to a specific preferences window? I was mostly just thinking out loud - and that thought came out because it would seem weird to both "Online Accounts" and a "Messaging and VoIP Accounts" items in the control center (that, and we have limited space there). I guess my view is that mainstream/branded accounts (such as Google, Facebook etc.) would be handled by the "Online Accounts" panel while something as baroque as ICQ (it was once big but isn't really anymore) would be handled by app-specific preference windows. Or maybe "Online Accounts" is used to configure not only something like GOA (e.g. branded accounts) but also Telepathy. I don't know. I'm not the best person to make that call - ask the GNOME designers? > This is somehow related to the "Contacts" thread, where it is said we > could replace the empathy contact list with the shell; in this scheme > there's no place any longer for that specific preferences window, and > it makes sense (to me) to have it in the online accounts panel, along > others. Sure. FWIW, I think we probably need some high-level design input that takes all these currently moving pieces and proposals into account. Again, I defer to the designers here. (Sorry if this sounds like a cop out. It's not. I agree this is an important thing.) Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Control Center items (Was Re: Online Accounts panel for 3.2)
David Zeuthen wrote: > >> I would imagine Telepathy/Empathy to use GOA to get the Chat accounts > >> that is configured in GOA (in the above example, it would be Google > >> Talk from zeut...@gmail.com and Facebook Chat for davidz25). I would > >> use an Empathy specific preferences window (not appearing in > >> gnome-control-center I think) to add e.g. my ICQ account. > > > > Could you elaborate on this, e.g. why would ICQ and other types of > > online accounts be deported to a specific preferences window? > > I was mostly just thinking out loud - and that thought came out > because it would seem weird to both "Online Accounts" and a "Messaging > and VoIP Accounts" items in the control center (that, and we have > limited space there). > I guess my view is that mainstream/branded accounts (such as Google, > Facebook etc.) would be handled by the "Online Accounts" panel while > something as baroque as ICQ (it was once big but isn't really anymore) > would be handled by app-specific preference windows. Or maybe "Online > Accounts" is used to configure not only something like GOA (e.g. > branded accounts) but also Telepathy. I don't know. I'm not the best > person to make that call - ask the GNOME designers? I am also of the opinion we want a single panel; but I think the design of the "online accounts" panel should allow the accounts that are currently in the "messaging and voip accounts" panel; nothing really new here, I had that old mockup in mind: http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/control%20center/web-services/web-services-2.png > > This is somehow related to the "Contacts" thread, where it is said we > > could replace the empathy contact list with the shell; in this scheme > > there's no place any longer for that specific preferences window, and > > it makes sense (to me) to have it in the online accounts panel, along > > others. > > Sure. FWIW, I think we probably need some high-level design input that > takes all these currently moving pieces and proposals into account. > Again, I defer to the designers here. > > (Sorry if this sounds like a cop out. It's not. I agree this is an > important thing.) No problem, GNOME is driven by design. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Control Center items (Was Re: Online Accounts panel for 3.2)
Hi, On Tue, Apr 19, 2011 at 11:24 AM, Frederic Peters wrote: > I am also of the opinion we want a single panel; but I think the > design of the "online accounts" panel should allow the accounts that > are currently in the "messaging and voip accounts" panel I agree. > ; nothing > really new here, I had that old mockup in mind: > > http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/control%20center/web-services/web-services-2.png Yeah, I looked at this too.. and it's somewhat what I had in mind - the only difference is that I think we need to support multiple instances (e.g. multiple Google accounts - I personally have both a gmail.com account and also a google-hosted fubar.dk account). While this might be a 5% thing (I think it's slightly higher actually), enough of us hackers use such a feature so not supporting it means a lot of people won't be eating the dogfood. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 10:27 +0200, Alexander Larsson wrote: > On Mon, 2011-04-18 at 09:29 -0700, Travis Reitter wrote: > > http://lists.freedesktop.org/archives/telepathy/2011-March/005369.html > > [4] > > This seems to talk about querying contacts from slow social web > services. Additionally if this is to be our story in evolution too we > need to be able to efficiently handle ldap contacts, which are really > important for enterprise deployments of email. This also needs a live > search approach, because we can't rely on a local copy of all ldap data. I'm considering two different cases: "shallow searching" (which is basically returning a client a filtered set of contacts) and "deep searching" (actually querying remote stores for more information). I haven't decided whether this difference will be exposed to clients or not yet. Either way, we'll be streaming in the contacts, so the client shouldn't need to care for most use cases. -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 12:45 +, Patrick Ohly wrote: > Another conceptual problem is that the server cannot communicate well > with the user. A client might pop up rich dialogs and ask the user for > help in cases that it cannot decide automatically (but designing such > a dialog is an unsolved problem). SyncML servers (and probably other > servers, too) don't have that option and instead fall back to > heuristics which fail inevitably in some cases. I think we'll have done something wrong if we need to ask the user to resolve their own conflicts (especially on a semi-regular basis in a process that may have started automatically in the background). I'm confident that sync is one of those things that users might request if you give them a checklist of features, but wouldn't want to deal with if they had to sort through hard-to-communicate conflict resolution dialogs like this. I think backups fall into a similar category, except they're even simpler. We all know how well most people deal with those :) Regards, -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
On Tue, 2011-04-19 at 09:08 -0400, David Zeuthen wrote: > Implementation-wise, I can see this as a very minimal daemon / library > that sits below libsocialweb, Telepathy, e-d-s and other APIs (e.g. > these libraries/frameworks would use this new framework) that is > dealing data online accounts. This daemon / library would This is awesome. It sounds like it will dovetail beautifully with the work I'm doing on the E-D-S side right now to overhaul the way we manage account info. It's all going to be unified under a single API which is fittingly named "ESource". My idea was that for online services like Google or accounts on a groupware server like Zimbra or Exchange, something provides a UI for the user to fill out the basic details. The tool then generates a set of specially formatted GKeyFiles and deposits them into a designated user directory which E-D-S is monitoring. E-D-S then sees the new key files, parses them into ESource objects, and adds them to an internal registry. If a client like Evolution is running, it would also notice the new key files and immediately present them in its source list, usually shown in the sidebar. What you're describing sounds like the missing piece in my project. Matthew Barnes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 13:48 +0200, Rodrigo Moya wrote: > On Mon, 2011-04-18 at 09:29 -0700, Travis Reitter wrote: > > As Frederic pointed out, we shouldn't be brainstorming on the 3.2 > > feature pages, so I thought I'd fill in some details/thoughts on the > > Contacts [1] idea here. > > > > The page suggests libfolks and/or libsocialweb for the implementation. > > The good news is that Folks 0.5.0 (released last week) added support for > > libsocialweb, so using Folks gets you both. In the process, Alban Crequy > > also added Contacts support for a few libsocialweb services in > > libsocialweb itself (Flickr, Twitter, Last.FM) and upstreamed Marco > > Barisione's Facebook support. The remaining lsw services (such as Vimeo > > and YouTube) don't have Contacts support yet, but it could certainly be > > added. > > > this makes a lot of sense, but we really need a way to send messages to > facebook/twitter contacts, or do other operations on the other services > (see photos from flickr, listen to music in last.fm, etc). > > So, are there any plans for a twitter/facebook client app? None that I know of. We already support Facebook's XMPP chat through Telepathy but not its email-like messaging system. Can third party clients use that anyhow? I thought that was completely walled off. I'm not terribly familiar with the details of Twitter - it just supports 140-char global posts and private messages between users, right? Handling sending these messages is probably best implemented as protocol handlers for Evolution, since they don't quite fit in with Telepathy's model and I think libsocialweb avoids communication to keep its scope narrower. There's also the question of whether we should be encouraging people to use Facebook's or Twitter's private message systems when email is quite a bit more open/easily-accessible/user-controlled. -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 10:01 +0200, Alexander Larsson wrote: > On Mon, 2011-04-18 at 11:52 -0700, Travis Reitter wrote: > > > On Mon, 2011-04-18 at 20:29 +0200, Johannes Schmid wrote: > > > > While using GNOME 3.0 on my desktop now for a week I wanted to share my > > > thoughs on the UI. The problem in the current situation is that the > > > shell provides a nice chat integration but to start a new chat you have > > > to use the "Contact List" window of empathy which feels totally > > > out-of-place. It is also one of the windows you really don't want to see > > > in the overview. > > > > Agreed. I'd like my general chat process to just be: > > > > , + > > By meta you mean the "windows key" thing? Right. > > which is the same way I launch all my applications in Gnome Shell (and > > is one of the most compelling features of it, I think). Like launching > > programs, you would be able to pause to see the full results list and > > perform more-specific actions (such as selecting the exact account and > > contact you want to initiate the chat from and to, as Empathy lets you > > do now). > > Yeah, this sounds like about the right thing. I'm thinking we could have > a new tab in addition to the windows and applications one listing > people, probably showing the online ones first, or at least making that > information prominent. Clicking on a person should let you easily send > mail, start a im conversation or send a file. Additionally these should > show up on the search results, and be possible to put in the dash. Yeah, a people tab makes sense too. Note that FolksIndividuals (ie, people) can be marked as favorites. If it's feasible, it'd be nice to determine membership in the dash based on whether contacts are favorites, though we may want to confirm that users generally only set a few people as favorites, since the dash quickly gets crowded even just with programs. And I'm guessing we'd want a gap to separate programs and people. > > > What Daniel and Salamon mocked-up is certainly a nice start but I think > > > a dedicated window for it doesn't fit with the overall shell design > > > well. > > > > I think it makes sense to have both. The shell search provider would > > focus on communicating with existing contacts (similar to launching > > programs), whereas the stand-alone program would be more focused on > > adding and managing contacts (which are much-rarer actions). And it > > still makes sense to have the communication buttons in the stand-alone > > program to make the use case of "add a person, start chat/call with > > them" smoother than adding them there, then going to the Activities tab > > to start the communication. > > Yeah, I think this is somewhat analogous to the file management > situation. If you just want to find or open a file you can use the > shell, but if you want to do more work you'd start the file manager. > > So, the gnome-shell integrated part is about day-to-day using of the > already set up stuff, whereas the contacts app is where you'd fill in > information, or do more complex stuff like link contacts or create > groups. > > There are other integration points we must think about too. Whatever we > come up with should imho replace the contacts pane in evolution, and > must allow interaction with evolution (dnd onto composer windows, etc). > Also, we should have something that corresponds to clicking on the "to" > button in the evo compositor to select a single email (or im if used for > elsewhere) address to add. There are vague/undefined plans to create folks-gtk at some point to supply an "Open Person..." dialog, a type-ahead completer, etc, since that would be generally-useful in a people-filled desktop. -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On Tue, 2011-04-19 at 10:54 +0100, Will Thompson wrote: > On 19/04/11 10:39, Alexander Larsson wrote: > > On Tue, 2011-04-19 at 09:53 +0100, Philip Withnall wrote: > >> Empathy uses the “text/individual-id” and “text/persona-id” drag targets > >> for dragging and dropping folks individuals and personas. > > > > Shouldn't you be using x-something for nonstandard types like these? > > Anyway, we'd need to add corresponding support to evolution too. Also, i > > think the current evolution contacts dialog dnds a vcard, which seems > > like a good thing to do too. > > Pidgin supports dragging and dropping application/x-im-contact and > text/x-vcard. > > Obviously it's unlikely that anyone will ever dnd between Pidgin and > Empathy, but it would be nice if Empathy supported these MIME types for > interoperability with hypothetical other apps that speak these formats. > (Perhaps Evo already understands both? I can't think where else > x-im-contact would be used.) If we're going to support dnd by vCard, we'll need to support vCard generation in Folks. We've intentionally structured FolksPersona/FolksIndividual to make that fairly easy, but it hasn't been implemented yet. -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Building mutter-3.0.0 for gnome3: FreeBSD: Sparc64 break
http://slexy.org/view/s2s8rkJyhN Adding disable-xsync to the configure arguments didn't work. I haven't tried disabling composite or xinerama. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Building mutter-3.0.0 for gnome3: FreeBSD: Sparc64 break
Hi, Le mardi 19 avril 2011 à 13:49 -0400, Super Bisquit a écrit : > http://slexy.org/view/s2s8rkJyhN > > Adding disable-xsync to the configure arguments didn't work. I haven't > tried disabling composite or xinerama. You need to remove -Wcast-align from the compiler arguments (it’s set by the configure script). See http://np237.livejournal.com/22270.html for explanations on a similar problem. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
On Tue, 2011-04-19 at 09:08 -0400, David Zeuthen wrote: > This daemon/library thing, let's call it GOA (Gnome Online Accounts), > would _not_ be a mechanism to access any of these services. But it > would provide e.g. libsocialweb, telepathy, e-d-s and so on with > either the username/password combo or the OAuth token, whatever is > appropriate. > > I would imagine Telepathy/Empathy to use GOA to get the Chat accounts > that is configured in GOA (in the above example, it would be Google > Talk from zeut...@gmail.com and Facebook Chat for davidz25). I would > use an Empathy specific preferences window (not appearing in > gnome-control-center I think) to add e.g. my ICQ account. This is very doable. On Meego Netbook we wrote a Telepathy Mission Control plugin that got the accounts from libsocialweb. Within Empathy's accounts capplet it then showed the Facebook account name, an enable/disable toggle (which was also shown in Web Accounts) and a button that launched the Web Accounts editor. There is also a different SSO plugin for Meego Handset. I mention the former one because it was specifically designed for the desktop and to integrate with Empathy. ~ The Web Accounts dialog on Meego is called 'bisho'. It's pluggable, allowing the provision for extra authentication mechanisms (e.g. for Facebook we required both the OAuth2 token AND a legacy Facebook Connect token *). * Tokens are stored in the keyring. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
