Following Xavier's steps, last week a new patch set has been commited to GNOME Online Account master repo, this time to add support for Facebook client-side auth flow, which does not require secret keys to work.

This means that since GNOME 3.4 it will be possible to enable Facebook support at configure time (yep, by default it's still disabled. Distributions will explicitly need to enable it for now). Currently only chat is supported.


The steps to enable it are easy:
Use --enable-facebook at configure time and compile+install as usual.A default FB application id is used, so you don't need to provide it.
Using the freshly updated goa-daemon (use --replace in case you're unsure) select online accounts from the control panel, add a facebook account (which should be now possible to select, along with at Google and Windows live if you've enabled it) and follow the on-screen instruction.
You'll need to authenticate yourself against Facebook and authorize the GNOME application.
Once your account has been created, set your presence to Available using Empathy or gnome-shell.
Now chat with your Facebook buddies \o/

It requires empathy (>=3.3.2), telepathy-gabble (>= 0.15.0) and of course gnome-online-accounts (the soon soon to be released 3.4.0, or directly git master)

Thanks to Xavier who backported to 3.4 my patches, originally meant for 3.6, and to Collabora who allowed us to improve Gnome Online Accounts!

Just to say it out loud in the hope someone else is interested in it:

I've been studying and I'm intentioned to write an open sourced Natural Interaction module for OpenNI or libfreenect which is able to do skeleton and gesture recognition.

Ideally and in the *very* long term I'd like to have something very close in functionalities to what the closed sourced NITE is for OpenNI, but to begin with a simple shape or movement recognition module will make me happy.

I don't know anything about the subject, including the basic of image manipulation, but if someone would like to have some fun thinking about it, let's join the forces!

There was an interesting issue in D-Bus, related to unicast vs broadcast signals, which led [edit: typo] to a small change in specs and which might be of some interest for D-Bus developers.

Unicast signals are not widely known and probably even less used, but they are possible.
They are useful, for instance, when you need to trigger an action from a single client, among your listeners.

Until some days ago, when a unicast signal was emitted, it was actually received by everyone listening to the signal's interface (unless a strict rule was added, unusual), waking up a number of processes which actually weren't interested in the signal.
Collateral effect, waking up cost apart: those processes might actually consider the signal as they were the actual recipient and take some action upon it. Bad.

Typical rule having this problem is "sender="org.foo,interface=org.bar".
Imagine several clients using this rule to listen to org.foo, but org.foo wanting to send a signal to :1.23 only.
Specifying destination=:1.23 for the signal object didn't really work since no dest=val was specified in the rule, allowing any destination actually matching it and all the listeners to be woken up anyway.

The problem with this situation was fixing the bad behaviour without filter out eavesdroppers, which actually wanted to receive the message even if not for them.

The solution is a sort of "eavesdrop opt-in", as Thiago proposed to add a keyword to DBusMatchRule, "eavesdrop=true false" which defaults to false and with which the listener declares that it really wants to eavesdrop, enabling it to receive messages (including signals) not meant for it (AKA eavesdropping).
Otherwise any message (again, including signals) with a specified destination won't match a filter with no or different destination. Also a rule with a specific destination won't match broadcast messages.


In other words, by default a match rule filter will match only broadcast messages or the ones specifically for you, unless you declare your very nature of eavesdropper by adding "eavesdrop=true" to your filter rule.

This is a behavioural change and consequently means a small amend to the D-Bus spec for 1.5.x.

It also means that if you maintain some code which acts as an eavesdropper, you should fix the code adding "eavesdrop=true" to your filter.
Note that it's only for 1.5.x branch; adding the "eavesdrop" keyword to a filter sent to a 1.4.x bus will fail as the keyword is not recognized.
An example on how to deal with this change keeping compatibility toward 1.4.x (stable branch) and 1.5.x (devel branch) at the same time is shown by this bustle fix. It checks for the feature presence and prepends the keyword if supported.

This probable is more a tweet [Edit: typo.Thanks to Robot101 :D] than a blog article, but since my last post was about the same subject, I felt it'd make sense to point this article out.

Its author analysed in a deeper way than what I did what the future looks (or is?) like and, I have to say, that after a bit of time spent on G+, I envisioned pretty much a similar future, reason for which I started following Edd Dumbill on G+ and of Twitter ;)
Also thanks to Zack for mentioning the article.

End of post, I said it was short, didn't I? ... and I made it longer than what originally conceived :)

Google+ opened to the small public some days ago, I'm not really going to comment anything about it for now.

The purpose of my post is actually reminding people of another interesting project, Diaspora, which actually fits several of my views over social networking.

I really hope that when Google will release API for its G+, there will be some chance for Diaspora to integrate with it and, most important, an opening for G+ to operate with Diaspora.

Most of us use(d) Facebook, now almost any geek I know is joining G+, some of them rejoicing its advent as an opportunity to leave Facebook for good.
That's not really my intention and I don't think it's the point of the whole social thing.

What about, instead, allowing the whole social sites to inter-communicate, exchanging information and letting users being able to see each other independently of the platform used?

That's clearly not possible so far :-), but it is the reason for which years and years ago (Internet-time rules apply) I got interested in FOAF, last year I crossed my fingers with Diaspora and now I'm doing the same about Google receiving some enlightenment bit and getting the right path about profile sharing.

The world of augmented reality is quite fashinating.

I recently got interested into Natural Interaction due to the popularity of Microsoft's Kinect and decided to package OpenNI for Debian.

OpenNI is a framework aiming to making natural interaction transparent to the user/developer, publishing a unified API and abstracting the access to different sensors and modules. Currently it supports some Asus sensors and there is a branch on github supporting also Kinect (which is the one we're packaging).

Some cool projects are already using OpenNI: ROS, PointClouds and OpenCV come to my mind immediately.

We'are working on OpenNI package in the Multimedia Maintainers group on Alioth, the package is still not ready to be uploaded to unstable and upstream has some major problems like the lack of SONAME in its produced library, so some communication with upstream is needed but for preliminary use the packages are in a decent state: OpenNI, PrimeSense Sensor, NITE (non-free).

NITE is a closed source module set for advanced body and scene recognition, unfortunately PrimeSense didn't opensource them, thus I decided to use the same approach of flashplugin-nonfree and write a downloader.

For the sake of completeness, unstable already has libfreenect which purpose is similar but specifically oriented to Kinect.

I am studying both and really hope that in the next future some open source project will make (at least) skeleton and hand recognition available under an open license. People are already working on it, according to Google.