Iain Lane
on 3 July 2017
I work at Canonical, on the desktop team. The team works on Ubuntu Desktop, publishing a release every six months containing the fruits of our efforts — or at least those ones that are ready enough for real people to use.
For the next release (out in October), we were given a big task. Switch the desktop environment from Unity to GNOME Shell. Make the switch as smooth as possible for our users, but at the same time respect upstream’s design decisions. That sounds like a good thing: if you are led by the upstream team, then there should be less to change downstream, right? This is something that the Ubuntu Desktop has had a reputation for in the past.
There are some immediate wins here — some of the GNOME UX didn’t sit very well with Unity. A good example is header bars and menus. Unity had a global menu bar at the top of the screen, and latterly a switch to put those menus in the window’s title bar (so-called locally integrated menus or LIM for short). When a window is maximised, its title bar merges with the top menu to give you some more screen space. It is a slick part of Unity’s design, but it didn’t work very well with header bars. It’s not possible to merge them into the top bar, and their design made the applications look out of place. We (mainly Trevinho) tried hard to make them fit in, but there was a killer problem: what do you do when LIM is enabled? We’re supposed to show the menus in the application’s title bar in that case, but with header bars there is no title bar, so no place to show the menus. We never solved that problem. Related to header bars, many GNOME applications also made changes to the way they provided menus, in most cases reducing them down to a top level item, which was in tension with Unity’s treatment of menus as important citizens.
We worked with GNOME to develop features to allow applications to adapt their user interfaces if the desktop environment likes to show menus. In some ways it was a good example of collaboration, but in others — like creating multiple UIs that application developers needed to support to feel “native” in both GNOME Shell and Unity — it sucked. We tried creating patches for applications to enable them to support these cases. Some upstream developers accepted these — thanks! — but others understandably didn’t want to maintain code they weren’t using or testing. So we were stuck with a bunch of patches to applications that didn’t look 100% awesome and were a bit of a pain to maintain. In the most annoying case we were maintaining a patch to add back a full menu structure that had been removed upstream. That means keeping up with feature changes and designing a logical way to lay out the menus, but doing this downstream. So it’s great that we get to remove this kind of patch now, and GNOME’s designers and developers will get to have their work delivered to Ubuntu’s users as they intended it to be.
Evince’s header bar converted to a toolbar in Ubuntu 16.04.
There are also problems, though. There are a very large number of Ubuntu users that are used to the way that the Unity desktop works currently. We care very much about these users, and we want to ensure that they are happy with their desktop after we switch them over to GNOME. We can get a long way by admitting that there is a certain inevitable period of adjustment that users will need to go through. But there will be occasions when we in Ubuntu have a genuine disagreement with an upstream decision, and it’s tricky to know what the right thing to do there is. Take a look at the survey conducted by Ken VanDine of the Canonical Desktop team. It is quite tempting to read the results of that survey, particularly where the views were tending strongly in favour of enabling particular extensions, as creating an obligation on us to implement the feature. But does it? The required next step, one that is currently ongoing, is to discuss the results with GNOME upstream and try to come to a resolution on each issue. In a lot of cases, even if the requested behaviour from Ubuntu isn’t completely agreed upstream, it will be possible to implement a setting that can be toggled downstream. In others where we diverge, though, it’s not clear to me what our response should be. Do we listen to the survey respondents and implement a feature that we couldn’t agree with upstream on — potentially irritating the upstream teams we are trying to build a good relationship with? Or do we disappoint those users that have expressed, sometimes quite clearly, their desire for a particular feature — even though we can say we lobbied on their behalf?
It looks like this is going to be the interesting release that reviewers have been asking for, but it’s not all on the surface. There are relationships to be built, and no doubt mistakes to be made along the way. See you at GUADEC to discuss these issues more.
The original post has been published on Iain’s blog.
