We're going to have a Folks & Friends hackfest and discussion at the Desktop Summit on Tuesday at 10:00. Meet in front of Kinosaal and we'll re-locate to a room with tables.
Topics include (but are not limited to):
User input. We'd really like to hear what you think about Folks and its Empathy and Gnome integration.
Constructive compliments
A follow-up on progress on the tasks we set at the Social IM/Contacts hackfest in Cambridge
We discussed a number of issues related to chat, video/audio calls, contacts, and social web service integration into Gnome. After each session, we filed all the necessary bugs to make sure we don't lose track of anything. Check out the session pages for notes and links to the related (mostly new) bugs.
It was especially good to have usability people Nick Richards and Allan Day on hand for our user-facing discussions. In general, I'm very happy to see Gnome continuing to move toward an interaction-design-driven development methodology. I'm quite confident that having a strong, consistent design-first, code-second process is the way we can (more than) close the usability gap that all-too-often exists between open source projects and their closed source counterparts.
Gnome 3.2 is going to have fantastic chat and contacts integration with the appearance of Gnome Contacts, Folks getting an EDS backend, Folks/Gnome Shell integration, and a number of other integration points. And it will only get better from there!
I would like to thank my employer, Collabora, for sponsoring the hackfest with a venue and especially the time of so many relevant developers (and to Guillaume for organizing the hackfest). Thanks also to the Gnome Foundation for additional sponsorship and Intel and Red Hat for sending along a few people each. This type of collaboration will help ensure that Gnome (and related platforms) not only keep up with our closed-source friends but begin to surpass them in ways we traditionally haven't (particularly usability).
We've focused the plans for Folks for the next few months and beyond in our much-revised Roadmap.
Some highlights:
Finishing the Evolution Data Server backend and making it the default primary backend
Adding search-based contact retrieval
Lazy-loading of attributes (to avoid a performance crunch as we've added a lot of attributes)
The Tracker backend will be the default primary backend for MeeGo until it officially switches to EDS for local contact storage. Around that time, we'll spin it off into its own module to make sure Folks can play well with out-of-tree backends.
A lot has been going on in the world of Folks lately, so it's time for another update. There have been a ton of fixes and clean-ups in the code (including some well-documented API breaks). We're narrowing down on another set of API breaks in our unstable 0.5.x branch before starting the stable 0.6.x branch. Our goal is to have very few (if any) API breaks after that.
Perhaps more importantly, we've added a lot of great features in the last few months. Read on for more (heavily-summarized) details.
I'd like to thank Intel for both sponsoring most of this work and understanding open source development. We were able to work in the open very early on and keeping things upstream was a goal, not a challenge. All the work is LGPL 2 or 2.1 and none of it requires copyright assignment.
New Fields
One big focus in 0.4.0 was adding a number of address-book-type fields, like:
• Role (within an Organization) • Birthday • Notes • Postal address
In all, contacts from Folks support most of the generally-useful fields you'd find in a typical address book.
The remaining features are new as of version 0.5.0.
Primary backend
A design goal of Folks, since the beginning, has been to simplify the way writes happen. There is, at most, one (primary) backend which provides contact linking hints to the aggregator and which stores address-book-like contacts (which are generally fully-writable for all supported fields). This has historically been (hard-coded as) our simple key-file backend but it is now configurable.
Tracker backend
The new Tracker backend acts as an address book and supports both reads and writes. Creating this help fill out our support for local, address-book-like contacts, so that portion of Folks is in decent shape now. It can be set as the primary backend, though the default remains the key-file backend. My colleague, Raúl, did a great job putting this and a sizable set of tests together.
libsocialweb backend
We've also added a backend for libsocialweb which lets us expose contacts from various web services through Folks. This required a little work on libsocialweb itself to add a Contacts interface and implement it for a handful of services (so far, Facebook, Flickr, Twitter, and Last.FM). Alban picked up on Marco's work in this area, added the last three services and implemented the newer Folks interfaces for the libsocialweb backend.
I think this area is especially exciting, since it lets us include contacts' details from a very wide range of services in the future, just by adding more services to libsocialweb.
Potential Matches
A long-requested feature has been the ability to hint matches between various contacts within Folks (since it's tedious to have to manually discover them all yourself). This clears the way for us to make linking nicer in Empathy.
In the future, we'll be looking into making this process even easier.
folks-inspect
Our handy folks-inspect utility has gotten a bit of attention to support the fields added since 0.4.0, making it even more useful for debugging.
I hope we can get our KDE-using friends interested in Folks now that we've got some decent Qt bindings!
Demos
The moment everyone has been waiting for:
(In case your browser can't play WebM: download here; YouTube version here)
The demos in the video are done through the QtFolks demo program because Empathy filters out non-IM contacts (at least as of this writing). But we'll certainly be supporting all Folks contacts in the Gnome 3.2 contacts features.
The latest release of Folks, 0.1.17, includes a new folks-import tool to import meta-contacts data from Pidgin. So if Pidgin knows frank.reynolds@example.com and the_penguin@example.org are the same person, folks-import will catch Empathy up-to-speed.
Now would be a good time to double-check your "Excuses for not switching to Empathy" list.
We've also got a nearly-working Pidgin backend to let Empathy support this functionality native in its Import wizard, but it was too late in the Gnome 2.32 release cycle to squeeze it in.
And farther into the future, Folks should perform reasonably aggressive auto-linking, which should make even semi-automated linking like this unnecessary.
Edit: Good News, Everyone! Sjoerd pointed out that the D-Bus fiddling in this post is unnecessary (as I'd hoped, but hadn't been able to manage). I mistook bgo#628738 for misconfiguration on my system.
In order to do development on Empathy, I've created another user on my system (creatively named "empathy-dev") and run my development versions of programs, libraries, and services through this user. This has a couple major benefits:
zero downtime - I frequently restart Empathy during development. Running the default system version of Empathy as my regular user means I can stay online as I develop.
fault isolation - if I horribly break my development environment (eg, the bleeding-edge libraries I depend upon introduce major bugs), it doesn't affect my system stability
It was somewhat non-trivial to create a good setup, so I thought other people might find this handy.
Throughout this short guide, I use references to /opt/gnome, which is the standard jhbuild $PREFIX. So substitute your development $PREFIX as necessary. I make a point to not use the standard Unix development $PREFIX (/usr/local) so that my regular user doesn't run the development programs or libraries (for stability and sanity; see below).
Skip the remaining steps this guide - it's needlessly complicated
First, we need to set up a few bits and pieces so your shell and D-Bus know where to find the development programs and config. I use a fairly standard D-Bus local session config file.
The important (and only non-standard, I think) part is:
/opt/gnome/share/dbus-1/services
This allows the programs installed in our $PREFIX to launch necessary services (eg, Mission Control, the Telepathy Connection Managers) through D-Bus activation.
Download this file, adjust it as necessary, and put it in /home/empathy-dev/.dbus-1
Add this to the end of your development user's .bashrc: export PATH=/opt/gnome/sbin:/opt/gnome/bin:$PATH
# let programs find any new icons, default config files, etc. export XDG_DATA_DIRS=/opt/gnome/share:/usr/share:$XDG_DATA_DIRS
# automatically start a D-Bus session bus alias dbus-setup="dbus-launch --config-file=$HOME/.dbus-1/session-local.conf" session_setup=$(dbus-setup) if [ $? -eq 0 ]; then echo "\nSet up D-Bus session for $USER:"; echo $session_setup eval export $session_setup else echo "\nFAILED setting up D-Bus session for $USER"; fi
Once you've got that set up, it's easy to launch the development version of Empathy as a different user:
slogin -X empathy-dev@localhost
Then, just run empathy and marvel at its independence from your main user's instance. However, if you haven't installed a newer version of empathy in $PREFIX/bin, this will just fall back to your system-installed version.
Fix this by setting up jhbuild and running "jhbuild build empathy". Find something to do for about 20 minutes. When you come back, if our dependencies haven't failed to build, you'll be able to run the latest version of Empathy as empathy-dev, without getting in the way of your system user.
Happy hacking!
-- dbus-launch will keep the dbus-daemon (and anything it activates) running by default after your development user logs out. There's a --exit-with-session option, but for some reason, if I use it here, about 30% of my keystrokes at the shell don't arrive. I'm flabbergasted, but it seemed completely tied to this dbus-launch option (I tried several times each way).
This is our "Link Contacts" dialog. Selecting a number of contacts on the left side designates which contacts will be included in the Individual (read: meta-contact) at right.
We currently auto-link contacts with the same service ID (foo@example.org) contained in multiple accounts. In the future, we're going to push as much into auto-linking as possible. My goal is that most users would never need to use this dialog. Until then, this dialog is how you designate meta-contacts in Empathy.
If you accidentally link together contacts you didn't mean to, you can simply open the Individual's info dialog and hit Unlink to start over.
One of the first benefits of meta-contacts is pulling together multiple modes of contact for a person into a single place. So if you've got a friend with separate work and personal IM, you can be an upstanding citizen and only send funny cat pictures to their personal IM address. (If they sign on to both at work, at least you tried your best).
We've kept the 1-click Chat/Audio Call/Send File/etc. actions for the (I think, more-common) case that you just want to communicate and you don't care about the specifics. This just uses any valid (ie, online) account for that Individual.
Thanks
This meta-contacts functionality is all possible thanks to the Folks project. It's a collection of libraries (so far, all distributed together) that collect contact information through various backends (Telepathy so far; many more to come) and aggregate Individuals (ie, People). Empathy was our starting point, but we really plan to integrate very well into the Gnome desktop and beyond. Think: typing -Alice- to start a chat with Alice through the Gnome Shell.
I'll discuss Folks in greater detail in future posts.
I'd like to thank my colleagues Philip "code factory" Withnall for helping with Folks development/Empathy integration and Empathy maintainer Guillaume Desmottes for letting us know exactly what we broke in each commit. And, of course, a special thanks to our employer, Collabora, for sponsoring us to work on this full-time.
Try it now!
Since you're no doubt very excited about these new features in Empathy, you can use them Right Now™ in version 2.31.91 (also coming to Debian experimental shortly). Be sure to file any and all bugs you run into, so this will be as solid a stable release as any other!
If software bugs have you leaping onto the nearest elevated furniture, no problem -- Empathy will, of course, by included in Gnome 2.32, coming to a friendly Linux distribution near you!
I'd like to congratulate the MeeGo team on shipping MeeGo 1.0 for Netbooks! It's nice to see user-experience-driven design on Linux (where it tends to be conspicuously absent), shipping in a complete product. It really shows, too -- the UI is extremely responsive and it makes the whole experience a joy.
Thanks to Intel hiring Collabora for some MeeGo work, I made a few contributions to the distro some months back. Some were evolution data server code clean-up, adding tests, etc. For the interesting, user-visible changes (that I didn't work on), see Michael Meeks's post about Evolution in MeeGo.
But the more visible contributions were to Empathy's account settings. Originally, Empathy's "first-run" account setup wizard and accounts settings dialog were in the same process as Empathy. This meant you had to launch Empathy before you could edit your accounts, which is a little awkward if you're another application. Telepathy accounts aren't Empathy-specific, so it makes sense that the dialog be independent (though it still lives in the Empathy source tree).
Thomas Wood's unified Control Center work appears MeeGo, and I adapted the Empathy accounts dialog to embed in it. The screenshot is fairly self-explanatory. When you access the accounts from the Control Center, you get a nice, full-screen version of the dialog:
Michael Meeks mentioned how small most netbook screens are. When you also factor in the MeeGo panel at the top of the screen, you can get situations where you need scrolling (but didn't on the full-sized desktop). So we added a scrollable view to the accounts dialog (to fit the full content of the Advanced section for protocols with a bevy of bells and whistles):
Since the actual dialog content is the same whether it's embedded or not, the same functionality works when it's stand-alone as well:
And because the MeeGo team understands open source software, these features were developed out in the open and have been included in the last few releases of Empathy. So if you don't have them already, you will soon!
This morning I was thrilled to hear that Google has openedup their high-performance video codec, VP8 and announced WebM, a container format with VP8 video and Vorbis audio. So now we've got a media format that's high-performance (not Flash), has low-power-requirements (not Flash) and is fully open and freely usable (not Flash, not H.264). The only missing piece is making sure it's widely supported (like Flash and, to a slightly lesser extent, H.264). So if this takes off, we can expect a much better experience for audio, video, animation on the web and on our phones.
There are a number of important players supporting this effort, including Collabora (GStreamer and our projects that use GStreamer, like Telepathy for multimedia calls), Google (YouTube, Android, Chrome, Chrome OS), Mozilla, Opera, Skype, Adobe (through Flash, surprisingly) in terms of software. And practically every major hardware player as well (AMD/ATI, ARM, Broadcom, Freescale, Logitech, nVidia, Qualcomm, TI, and more). This should make the problem of hardware support (which has traditionally been a problem for open media formats) a moot point.
![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
