Debarshi's den

Archive for the ‘GNOME’ Category

Yorba’s Geary Fundraiser

leave a comment »

The fine folks at Yorba are raising money to improve Geary, their shiny new email client for GNOME.

Please donate if you want to make a difference.

Written by Debarshi Ray

8 April, 2013 at 00:20

Posted in GNOME, Yorba

Submit your talks for GUADEC 2013

leave a comment »

It is still snowing in Brno, but there is no reason to believe that summer is far away. So, please go ahead and start submitting your talks for this year’s GUADEC.

This year’s conference will focus on:

  • Design of the core user experience (core applications, shell, toolkit)
  • Design of the developer experience (tools, documentation, services)
  • Integration and extension of the operating system plumbings into the core UX
  • Application development and deployment
  • Integration of web technologies into the GNOME user experience
  • Improving the user experience on different form factors
  • Outreach to new contributors
  • Organization and governance of the project

I am sure you have a lot of cool things to talk about and the deadline is barely three weeks away on the 27th of April. So, hurry up and send those talks our way. We hope to see you in Brno in August.

Cathedral of St. Peter and Paul

Written by Debarshi Ray

4 April, 2013 at 00:50

Posted in GNOME, GUADEC

GNOME Online Accounts and IMAP / SMTP

with 3 comments

Starting from GNOME 3.7.91, you can configure your IMAP/SMTP accounts via GNOME’s single sign-on framework and then use them from Evolution.

Using a GOA configured IMAP/SMTP account in Evolution

Many thanks to Matthew Barnes for making the required adjustments in Evolution Data Server and making sure that it landed in time for the 3.8.0 release later this month.

Written by Debarshi Ray

5 March, 2013 at 02:03

GNOME meets ownCloud

with 10 comments

Now that we are in the middle of the various freezes in preparation for GNOME 3.8, it is a good time to talk about some of the things that happened over the last six months. One such thing is the integration of ownCloud in GNOME. Go to the Online Accounts panel in Settings (hit the super key or the Activities button and type “online”) to enable your ownCloud account, and you will be able to access your calendars, contacts and files from GNOME.

Calendars and contacts can be accessed via CalDAV and CardDAV from their respective tabs in Evolution. Files in your ownCloud storage show up as volumes via WebDAV in Nautilus and GtkFileChooser.

ownCloud calendar in Evolution

ownCloud contacts in Evolution

ownCloud files in Nautilus

Many thanks to Milan Crha for making the necessary changes to hook up Evolution with ownCloud in time for 3.8.0.

Written by Debarshi Ray

4 March, 2013 at 22:48

Setting up an ownCloud instance on OpenShift

with one comment

Ever since portknox.net suspended their gratis offering and sereinity (from #fedora-devel) shut down his server, I had run out of instances that I could use for working on bringing ownCloud closer to GNOME.

Few days ago, Michael Scherer pointed me to ownCloud-OpenShift kickstart, and it is really as easy as the README.md claims to be.

Thanks to it I have now got myself owncloud-lostcase.rhcloud.com.

Written by Debarshi Ray

21 December, 2012 at 18:34

GUADEC 2013 is in Brno

leave a comment »

It is decided and final! GUADEC 2013 is going to be in Brno from August 1 to 8 at the Brno University of Technology.

Mendlovo náměstí

Written by Debarshi Ray

21 November, 2012 at 20:25

Posted in GNOME, GUADEC

GNOME Online Accounts: why it is the way it is

with 23 comments

This keeps cropping up every now and then, so I thought of writing this down once and for all. Private conversations are poisonous for a community driven free software project like GNOME.

Background

In the new GNOME 3.x series there has been a push to integrate the user’s online accounts into the desktop. Towards this end, almost a year ago, a new single sign-on (SSO) framework was written for GNOME 3.2. However, more recently, Ubuntu created its own SSO to achieve a similar objective.

An SSO is only as effective as the applications that use it, and having to support two different frameworks with their own set of APIs and ways of doing things is a pain for application developers. Given the long history between the two projects, it is not surprising that they also share quite a few applications, and in turn developers.

The Split

Ubuntu’s SSO is based on the one used by MeeGo, while GNOME wrote its own. I do not know why Ubuntu decided not to use GNOME Online Accounts (GOA), because they decided to switch after GOA was born.

But why did GNOME write its own when MeeGo already had one? Sounds like NIH, doesn’t it?

However, it is a bit more complicated than that. MeeGo (and now Ubuntu’s) SSO has a DBus daemon written using Qt. We have been down this road before, most recently with Maliit. The daemon would have had to be rewritten without Qt using GObject for it to be a part of GNOME. This problem has only increased with Ubuntu reimplementing the signon-ui service using QWidgets and QtWebKit, which is then embedded into System Settings using XEmbed. MeeGo’s implementation of this service was proprietary.

Secondly, MeeGo used libdbus-glib-1 instead of GDBus when the discussion to use it in GNOME first took place. I do not know whether it has changed since then or not. We have been actively trying to move away from libdbus-glib-1 to GDBus. One of the problems with libdbus-glib-1 is that it is not thread-safe. If we mix the two in an application, the same process will end up having two connections to the DBus daemon. We want to avoid that. This means that we would have to migrate it to GDBus.

Both of these would require non-trivial changes to the code and hence it is not as NIH as one might think it to be.

Not to mention that the pass through authentication scheme used by MeeGo would only make it harder to patch existing applications to use the SSO.

Ofcourse, one can argue that we could have still tried to push the needed changes to MeeGo. Maybe we could have done so, but I am not convinced that it would have made life any easier for GNOME, MeeGo or Ubuntu. More on that later.

Third-party Plugins

One of the ways in which Ubuntu’s SSO differs from GNOME’s is that it allows third-party plugins to offer new account types or providers. They leverage this to make Empathy export its code for adding chat accounts (Jabber, SIP, etc.) via external plugins. While we do agree that plugins can be useful, we are not too excited about allowing third-party or external plugins. We intend to support in-tree plugins for GNOME Online Accounts.

Third-party plugins lead to a kitchen sink. There is no way you can stop them from stepping on each others feet. This was one of the reasons why we stopped supporting external panels in the System Settings against a lot of stiff opposition.

Fictitious screenshot

Fictitious screenshot showing duplicate providers supplied by 3rd party plugins.

Someone’s kitchen sink can be another’s extensibility. However GNOME 3 is still young and I think it is important to stay clear of kitchen sinks at this point.

There is no fundamental reason not to have all the different types of chat accounts supported by Empathy in the SSO itself, as long as we take care not to clutter the UI and keep the popular ones separate from the rest. The thumb rule for adding a new account type to the SSO is to have a GNOME application that hooks into it. In this case, we have two — Empathy and GNOME Shell.

Thirdly, having an application provide a new account type via a plugin violates the basic layering of the GNOME platform. This is mostly a good taste vs. bad taste thing. The SSO is supposed to be right at the bottom serving accounts and credentials. Things like libgdata, libzapojit, libsocialweb, etc. sit on top of it and leverage the information as GDataGoaAuthorizer and ZpjGoaAuthorizer currently do. Then you have the applications using these libraries to offer something useful to the users. In fact Empathy already works this way in GNOME.

Having a circular dependency where applications provide critical functionality to the SSO via plugins, which they then consume, only complicates the whole platform.

GNOME and Ubuntu

Recently GNOME and Ubuntu has diverged quite a bit in their plumbing layers. Think in terms of gdm vs. lightdm, systemd vs. upstart, gnome-shell vs. unity, and so on. Both projects are focused on building a vertically integrated product, and it is only fair that they get the liberty to make decisions that are best for them and be free to fail or succeed without getting flamed.

Then there is the issue of copyright license / assignment agreements that Canonical asks for those components that are hosted on Launchpad. For example, signon-ui. I am not a lawyer, but my understanding is that GNOME has always stepped carefully when it comes to signing these agreements with a company because it makes it tricky for competing commercial entities to participate.

This is why I am doubtful that we would have ever been able to merge or share everything because this divergence is only going to increase. The SSO will closely tie in to the way we will do application bundles and sandboxing in GNOME, which in turn will depend on systemd. These things are still being hotly discussed within GNOME, so I do not know what the exact implementation will be neither do I know what Ubuntu plans to do, but it is possible that theirs will be different.

So, if one wants to make sure their application is both a GNOME and an Ubuntu application they will have to spend some extra effort to make sure that it works well on both platforms. But it is not bad as it sounds. Both GNOME and Ubuntu are doing a great work of taking free software on the desktop forward, and the effort spent in supporting both will only be rewarded by a greater number of users.

Written by Debarshi Ray

6 October, 2012 at 05:36

Posted in GNOME, Online Accounts

Thanking every contributor

with 4 comments

I am of the opinion that every contributor to a free software project should be thanked. No matter how prolific or sporadic. There are many ways to do it — having a section in the release notes is one common example, the AUTHORS file is another, or if it is a program with a graphical user interface of its own then the about dialog is a very good option. In fact, the about dialog is the best option because it is more persistent than the release notes (ie. does not change from one release to another), and is shinier than a plain AUTHORS file. Not to mention the fact that it is much more visible.

However, it is a pain. While there are scripts lying around to generate the credits for the release notes, I have not seen the same for the about dialog. No doubt it is outdated in every application, which is a shame.

We can do better. For Photos, I decided to generate the list from Git. First I generate an AUTHORS file, and then use it to create a pair of C header and source files which contain the array of strings that can be fed to gtk_about_dialog_set_authors. From now on every new contributor will see her name show up in the about dialog immediately after making her first commit.

It would be nice if this caught on and other application maintainers decided to do something similar.

Written by Debarshi Ray

16 August, 2012 at 22:43

Going to GUADEC 2012

leave a comment »

In a few hours I will be flying to A Coruña to attend GUADEC 2012. On the 26th, I will be talking about GNOME Online Accounts

Written by Debarshi Ray

25 July, 2012 at 07:37

Online Accounts improvements

with 7 comments

With the new GNOME 3.5.3 release this week, it is a good time to highlight the UI/UX related patches against the Online Accounts panel that got merged recently. There isn’t much to write about because the changes are visual. So I will leave you with a few screenshots.

Empty Online Accounts panel

Adding a new account

Online Accounts panel with configured accounts

Written by Debarshi Ray

25 June, 2012 at 18:47

Posted in GNOME, Online Accounts

Follow

Get every new post delivered to your Inbox.