Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting our team. We will be in touch shortly.Close

  1. Blog
  2. Article

Iain Lane
on 3 July 2017

Switching from Unity to Gnome-Shell: first challenges

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.

Related posts

30 May 2023

Join the Ubuntu crew at GUADEC 2023

Ubuntu Article

Save the date, join us in Riga for GUADEC 2023!  GUADEC is the GNOME community’s yearly event. A great week of talks and workshops brings hundreds of GNOME developers, users, supporters and community members together. This year GUADEC will be held in Riga, Latvia, from July 26 to July 31.  GNOME is an outstanding Open ...

Adam Szopa
21 October 2022

What’s new in Ubuntu Desktop 22.10, Kinetic Kudu

Desktop Article

The latest release of Ubuntu Desktop comes with improved productivity features, a new official flavour and performance improvements for Bluetooth devices. ...

Holly Hall
30 June 2022

Star Developers are here!

Ubuntu Article

We are happy to announce that the newest community feature of the Snap Store is here: Star Developers! Background  In the Snap Store, we have a fantastic community where members can discuss topics in the forum, develop snaps and help others. Currently, the Snap Store has verified accounts; verified companies have a green tick by ...