从Unity过渡到Gnome-Shell：面临的首要挑战

Mark Do 2017年7月17日评论已关闭阅读 10,562 次

来自于Ubuntu开发团队的信息：我是 Canonical 桌面团队的一员。我们的团队负责开发 Ubuntu Desktop，每半年发布一个发行版，其中凝聚了整个团队辛勤努力的成果——至少是可以放心让实际用户使用的功能。

对于将于 10 月推出的下一个发行版，我们接到了一项艰巨的任务：将桌面环境从 Unity 过渡到 GNOME Shell。确保用户的过渡尽可能平稳顺利，同时尊重上游的设计决策。这听起来不错：如果以上游团队为主导，下游要做的改动应该比较少，对吧？过去，Ubuntu Desktop 一直以此著称。

新的转变有一些显而易见的好处—— 有些 GNOME UX 之前与 Unity 的兼容性不是很好。顶栏与菜单就是一个很好的例子。Unity 原来在屏幕顶部设有一个全局菜单栏，后来改为将这些菜单放在窗口标题栏中（我们称之为本地集成菜单，或简称为 LIM）。当窗口最大化时，窗口标题栏会与顶部菜单合并，给用户让出更多的屏幕空间。这是 Unity 设计中一个讨巧的特性，但对于顶栏来说效果不是很好。这些菜单无法合并到顶栏中，并且它们的设计也使应用程序看起来不太协调。我们（主要是 Trevinho）已经尽力使它们融入布局之中，但还有一个致命的问题：当启用了 LIM 时，怎么办？这种情况下，我们本来应该在应用程序标题栏中显示菜单，但是由于使用顶栏时没有标题栏，因此也就没地方显示菜单。这是一个解决不了的难题。提到顶栏，很多 GNOME 应用程序还会修改提供菜单的方式，多数情况下是将菜单降为顶层控件，而这又与 Unity 将菜单视为重要元素的做法相矛盾。
我们曾经与 GNOME 合作开发过一些功能，当桌面环境希望显示菜单时，让应用程序可以调整其用户界面。从某些方面看，这堪称上下游协作的一个良好典范。但从其他方面看，例如当应用程序开发者需要让多个用户界面在 GNOME Shell 和 Unity 中都有“原生”的使用体验时，情况就会变得很糟糕。我们曾经尝试为应用程序创建补丁，让它们能够支持这类情况。有些上游开发者能够接受这些，在此特别感谢他们！但是，也有些人不想维护他们没用过或没测试过的代码（有这种想法也可以理解）。所以，我们就这样被一堆看起来有些鸡肋、维护起来又令人头疼的应用程序补丁所困。最令人恼火的一次情况是，我们要维护一个补丁，将上游已删除的一整套菜单结构重新添加回来。这意味着我们要紧跟功能变化，设计出一套符合逻辑的菜单布局方式，但这些工作全部在下游完成！现在过渡到 GNOME Shell，终于可以摆脱这些麻烦的补丁，这种感觉太好啦。GNOME 的设计师和开发者也将可以按照自己的想法为 Ubuntu 用户开发丰富的功能。

Evince 的顶栏在 Ubuntu 16.04 中转变为工具栏。
不过，除了上面提到的好处，问题也在所难免。目前，有很大一部分 Ubuntu 用户已经习惯 Unity 桌面当前的工作方式。我们非常重视这部分用户，并且希望确保他们在过渡到 GNOME 后能有满意的桌面体验。我们承认用户需要一段不可避免的调整期才能适应，因此这次过渡可能会是一个漫长的过程。但是我们总会遇到 Ubuntu 的开发与上游的决策发生真正分歧的时候，这种情况下谁也说不好怎样才是正确的做法。我们可以看一下 Canonical 桌面团队的 Ken VanDine 所做的调查。调查结果很令人跃跃欲试，尤其当观点强烈倾向于启用某些特定扩展时，就像我们有义务实现该功能一样。但真的如此吗？接下来我们要做的，也是目前正在做的，是与 GNOME 上游讨论这些结果，并尝试就每个问题得出决议。在很多情况下，即使 Ubuntu 请求的行为得不到上游的完全同意，下游也可以自己实现可切换的设置。但是对于其他存在分歧的情况，我确实不清楚我们该怎样回应。我们到底是倾听受访者的声音，实现一项无法与上游达成一致的功能，并可能因此惹恼我们正在努力与之建立良好关系的上游团队，还是让那些已经坦言甚至明确表示需要某项特定功能的用户失望（尽管可以说我们已经代为转达了他们的诉求）？

这次的发行版看起来就像评测人员期望的那样，将是一个非常有趣的版本，但实际远不止大家表面看到的这些。我们还有许多关系要建立，毫无疑问也会伴随一些错误。我将在 GUADEC 上继续与大家深入探讨这些问题。
原文发表于 Lain 的个人博客。