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

来自于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 的个人博客。



为您推荐

说点什么

您将是第一位评论人!

提醒
avatar
wpDiscuz