Насколько сложно объединить Unity & Gnome-Shell?

Я не думаю, что полезно, чтобы рабочий стол Linux был слишком фрагментирован, вилки должны воссоединиться с основными проектами и, таким образом, сделать Linux более опытным.

Итак, если в какой-то момент в будущем сообщество / Canonical должно решить между Unity и Gnome-Shell, как сложно было бы объединить два проекта?

Считайте, что Unity и Gnome Shell (aka Gnome3) разделяют почти весь стек операционной системы. Часть, которая сильно отличается, – это часть оболочки, визуальные элементы. Я боюсь, когда дело доходит до снарядов, их невозможно консолидировать.

  • Gnome Shell основана на JavaScript, и разработчики категорически отвергают любой код, который не является javascript.
  • Unity основан на Python, C и Vala, он использовал тот же самый композитор, что и Gnome Shell, но перешел на Compiz, потому что он был слишком медленным.

Скорее всего, будет предложение идей между проектами. Каждый проект будет прав, некоторые вещи ошибочны. Проект с лучшим чувством дизайна, смирением принять то, что хотят пользователи, и в конечном итоге команда с лучшей экономикой (больше разработчиков) будет развиваться быстрее и лучше со временем.

У них, конечно же, много различий как на техническом, так и на функциональном уровне. Они также сосредоточены на отдельных (хотя и подобных) творческих направлениях, и они оба очень развиты, но не окончательны. Легко было бы за несколько лет до того, как он обосновался с чем-то, что докажет, что оно хорошо работает.

В любом случае идеи могут пересекать пустоту. Это явно произошло уже несколько раз, и в этом нет ничего плохого, и хотя он помогает на уровне интерфейса-идеологии, он не делает ничего, чтобы помочь разработчикам объединиться за общим языком программирования или композитором.

Я думаю, что это, вероятно, закончится тем, что одно решение «выиграет» (через прогресс в отношении полезных функций) и будет принято другим лагерем, но, опять же, существует несколько типов разработчиков, более строгих, чем разработчики FOSS. Это может даже взять что-то вроде Wayland (по сути, заменить X своим собственным слоем компоновки), чтобы продвигаться вперед.

Я бы не стал делать ставку на то, чтобы ломаться далеко от другого. По крайней мере, только до тех пор, пока основные технологии не изменятся.

Кажется маловероятным. Большая часть единства основана на compiz, тогда как GS создала новый инструментарий (основанный на Mx) и стек, а также новый WM. GS мог легче подражать Unity, чем наоборот, и я не удивлюсь, если увижу скины, которые это сделали, но они, вероятно, не собираются интегрироваться. В сущности, это проблема оконных менеджеров. Gnome построил собственный WM (действительно порт Metacity to Clutter со многими улучшениями), а GS – плагин для Mutter. JS используется для почти всех элементов интерфейса, в то время как C используется в библиотеках (Mutter находится в C). JS является неотъемлемой частью опыта (не плохая идея, учитывая, сколько усилий вкладывается в исследование JS, поэтому вещи должны быстро улучшаться, а не то, что им НЕОБХОДИМО). Unity взяла существующий WM и расширила его и построила интерфейс вокруг него (очень похож на GS), но использовал существующие инструментальные средства, поэтому сложнее создать gl контексты в Unity, если вы не используете Qt (я предполагаю, что они в конечном итоге перейдут к нему полностью) , Unity является хорошим выбором для Canonical, так как они хотят создать уникальную среду, так как она многократно использует, но не следуя за течением вверх, они рискуют всегда оставаться за технологической кривой в гноме (опять же, еще одна причина, по которой они, вероятно, перейдут на Qt). Итак, если бы вы могли убедить Гнома или Каноника отказаться от одного из своих WM, вы могли бы получить слияние, но в чем смысл? Пусть они создают 2 разных настольных компьютера и позволяют видеть, что лучше.