Tales of software craftsmanship

Tales of software craftsmanship

The About dialog goes social – now for all of KDE!

Remember a year ago when I blogged about the Social About dialog? The dialog in Amarok that replaces the dull old About dialog with something more colorful?

Last Wednesday, after an almost complete rewrite and a few days of review, I committed my KDElibs port of the Social About dialog to trunk, to be released with KDE SC 4.6.

What does this mean for end users?

The Social About dialog is a small built-in Social Desktop client, available in any KDE application. Its purpose is to bridge the apparent gap between users and developers by providing an additional communication channel right inside the application. As a user, you will be able to see some more information about the project’s contributors, and directly access a contributor’s online presence as exposed by openDesktop.org or another provider which implements the Open Collaboration Services (OCS) API, as chosen by the authors of the app.

Looking back at the time when I wasn’t a KDE dev I can distinctly remember that I used to perceive KDE contributors as a reclusive and elite clique of people somewhere far away, with mad skills, encircled by an aura of awesomeness. While I can testify that a lot of KDE people really do have superpowers, I’d hardly call them reclusive. To quash that misconception, I’m giving you, the user, a way to get to know the people behind the project. You might even be surprised to find out that there’s an active bunch of KDE hackers in your very city or that the authors of your favorite KDE app share your taste in music.

The Social About dialog replaces the old “About Project” dialog and exposes the Social Desktop features if all of the following conditions are met:

  • You are running KDE 4.6 or later
  • You have a working internet connection
  • The contributors of the application you are using have chosen to add their usernames for an OCS provider such as openDesktop.org.

The new Social About dialog, as it appears in a test application using KDElibs trunk.

For every contributor who wishes to share his OCS data the dialog shows fields such as location, blog, homepage and social network profiles including Facebook, LinkedIn, Last.fm, Twitter and several others.

If there’s no internet connectivity or if a contributor does not wish to expose his data on the dialog, the appearance of an item will be very similar to how it was in the old offline about dialog.

What does this mean for application developers?

The general idea is to convey the message that the project is developed by real people, with another channel of user-developer interaction right inside the app.

This is a drop-in replacement for the old KAboutDialog. Obviously if you don’t touch anything in your KAboutData the dialog will be very similar to how it used to be, aside from some minor cosmetic differences i.e. you need to opt-in to use it. The dialog will also be in offline mode if KDElibs is built with the mobile profile (which is expected to remove the Attica dependency). By default, the Open Collaboration Services provider is openDesktop.org, and the contributor’s usernames can simply be appended to the KAboutData::addAuthor and addCredit calls.

In Amarok the experience has been positive, and there have been no instances of abuse (such as bug reporting in the wrong place or harassment) that I know of that could be attributed to the communication channels exposed by the Social About dialog.

If you already have a profile on openDesktop.org (or another OCS provider), don’t forget to update it before adding your username 😉

Why was this an almost complete rewrite?

For several reasons. At the time I wrote Amarok’s Social About dialog, Attica (the library that talks to the Open Collaboration Services API used by openDesktop.org and other providers) was still a moving target, and I needed to throw away some of the code that used now deprecated and removed API elements. Also, Amarok’s Social About dialog couldn’t work as a drop-in replacement for the old KAboutDialog since the data structures used by Amarok’s Social About dialog were a hack designed to make the it work with an unmodified KAboutData and OCS usernames thrown on the side. Finally, the persons list in Amarok’s Social About dialog was just a bunch of widgets in a layout, and lacked many of the performance and reliability advantages offered by the new dialog which uses model/view.

I wish to thank Frederik Gladhorn for his useful suggestions and review, the Amarok team for their useful suggestions and support in surviving git-svn and the developers who reviewed my submission on KDE’s Review Board for their patience, attention to detail and help.

What’s missing?

Aside from some minor planned improvements under the hood, the most prominent missing interface elements are about a dozen icons that represent links provided by OCS, such as Facebook, Identi.ca, LinkedIn and other social network profiles. We already have some of those from Amarok’s Social About dialog, but I still have to check if inclusion in KDElibs would be possible because of licensing restrictions, and what do KDE artists have to say about the appearance of said icons in the context of Oxygen.

And obviously, we are missing the data, so if you are a contributor for a KDE application and you feel like joining the Social Desktop bandwagon, go ahead and add that username!

13 Comments

  • Reply Jason |

    Why introduce two classes? Why not have this replace the old KAboutDialog, and have a global system wide option (in system settings) to disable social network connections if the user doesn’t want it.

    Or, if you want to leave it up to the app authors, KAboutDialog::enableSocial(bool)

    • Reply Téo |

      I’m sorry I wasn’t very clear with this, I’m not introducing two classes. The Social About dialog was a separate class in Amarok for the reasons I explained in the post, but the new one in KDElibs does replace the old KAboutDialog.
      If the app authors don’t wish to have social features they simply don’t add their OCS usernames, and the dialog takes care of laying out the items so that it doesn’t look like something’s missing.

    • Reply Téo |

      That’s definitely an idea to consider. Unfortunately KDElibs is in string freeze now and adding a donate button would very probably require the addition of a new string.

  • Reply Shantanu Tushar |

    One minor annoyance this has is that when I open the About dialog, kwallet displays the dialog “Application foobar has requested access to the kdewallet wallet”, per application. Because its per application, even if the user says “Allow Always”, it will appear at least once in each application.
    Any way to avoid this? I think it should be possible, because the OCS data the dialog is displaying won’t need the user’s credentials …

    But anyway, awesome work 🙂

  • Reply Tsiolkovsky |

    Is this working for translators too now. If I remember correctly from Amarok the translators tab didn’t feature this very nice social aspect.

    • Reply Téo |

      Yes and no. The translators tab now uses the same view that the other tabs use so it looks consistent. However, since the translators data structures are handled quite differently there’s still no way to add the translators’ OCS usernames.

  • Reply renoX |

    I’m not sure that the separation between developers and other contributors is really needed or useful: it seems to me as counter-productive.

    You could put everyone in the same screen, grouping people by activity.
    Of course if people do both localisation and programming, there’s an issue..

    • Reply Téo |

      This is a social distinction rather than a technical one that’s been around in many KDE subprojects for quite a while, and it is not between coders and general contributors, but rather between a core team of contributors (“Authors”) who maintain the project and have shown significant commitment for years, and an extended team of contributors including regular and former ones (“Thanks to”).
      “Authors” are the ones who steer the general direction of the project, if there’s only one author he’s sometimes called “the maintainer”. They are the ones who enforce code quality and manage the brand, and also get the blame if something’s wrong – it’s a role with more responsibility.
      The “Thanks to” list of contributors holds all the people who send patches or even commit regularly and might be elected authors one day, but have not been involved for a long time or their involvement has been in some way limited to solving particular issues rather than pushing the whole project forward. A somewhat improper but still alternative way to call those in some apps would be “external contributors”, though I personally wouldn’t call someone “external” just because he hasn’t been around for very long.
      The important point is that it’s not political, it’s not a way to segregate an elite from an underclass, but simply to credit everyone while also showing who is responsible for the project in the long term.
      As far as I know in most situations in KDE coders, artists, community managers, etc. are all treated equally and are equally eligible for a place in the “Authors” list for an app.

Post a comment