[devel] RFC: XDG menus

Alexey Rusakov ktirf at altlinux.org
Fri Jul 24 01:04:13 MSD 2009


Доброго времени суток.

У меня сейчас будет большое письмо, зато про тему, в которой все
(считают что) разбираются :) - я сейчас поговорю про меню в
дистрибутивах, создаваемых на базе технологий ALT Linux.

Почему я вообще собрался об этом написать. В связи с багом [1] я полез
разбираться в том, как устроены XDG menus (то есть меню, соответствующие
документу fd.o[2]). На середине пути я сам сотворил ещё один баг [3], и
по обсуждению в нём ещё крепче задумался над тем, как же оно всё-таки
должно быть устроено. Дальше я излагаю свои мысли по поводу в расчёте на
дальнейшее доведение мыслей до реализации. Если у кого есть мысли и/или
информация по другим известным дистрибутивам, делитесь: я на другие
дистрибутивы пока не смотрел.

Я предполагаю, что читающие уже ознакомились хотя бы по диагонали с
fd.o-шным документом [2] и соответственно не рассказываю принципы сборки
меню из отдельных .menu-файлов (внимание, .menu-файлы - это не файлы от
старого Debian menu, это совсем другое - см. [2]). Ещё одна важная
оговорка: наполнение меню .desktop-файлами здесь не обсуждается, это как
раз забота конкретных .menu-файлов. Речь идёт только о построении
иерархии меню, причём я для простоты ограничиваюсь только меню
Applications (бывают и другие, в GNOME, например, есть settings.menu).

Ну, хватит уже с преамбулами. Итак, насколько я себе представляю,
имеются следующие компоненты, из которых нам надобно собирать меню
(названия компонент условны):
applications-base.menu. Некая базовая часть, общая для всех
дистрибутивов и всех графических сред. Сейчас это
файл /etc/xdg/menus/applications.menu
applications-merged/*.menu. Добавки от конкретных подсистем. Честно
говоря, я не уверен, что такая сущность вообще имеет место быть (по
крайней мере в Applications), потому что единственный мне пока известный
случай (java-sun-desktop) оказался ошибочным и на самом деле в
Applications свою структуру добавлять не должен.
applications-<distro>.menu. Часть брендинга под конкретный
дистрибутив/линейку, не зависящая от DE (грубо говоря, если мы делаем
Junior на KDE и Junior Lite на XFCE, эта часть должна быть для них
одинаковой). Сейчас опыта создания таких частей просто нет, но в
Школьном проекте в чём-то близкая задача была.
<de>-applications-base.menu. DE-специфичная структура меню от апстрима
соответствующей графической среды. Сейчас она добавляется через
файлы /etc/<DE>/xdg/menus/applications-merged/applications.menu , что не
очень следует [2], но и не противоречит. В [2] предлагается для этого
использовать файлы /etc/xdg/menus/<DE>-applications.menu (об этом есть в
обсуждении [3]).
<de>-applications-merged/*.menu. DE-специфичные добавки от отдельных
подсистем. Опять-таки, теорема существования пока не доказана.
<de>-applications-<distro>.menu. DE-специфичная часть брендинга.
Делается попытка сделать такую в пакете
branding-altlinux-workbench-gnome-settings, но попытка сопряжена с
хаками (см. опять же баг [1]).
applications-admin.menu и <de>-applications-admin.menu. Навороты
администратора рабочей станции, общие для всех пользователей. Вообще в
хорошем случае их быть не должно, но случаи бывают разные. NB: крайне
маловероятно, чтобы админу понадобилось выбросить всё меню (1-6) целиком
и сделать своё.
applications-user.menu. Пользовательские навороты. Этой части я далее не
касаюсь: она лежит у пользователя в домашнем каталоге и пользователь
может для себя сделать любой закат солнца, какой хочет.

Если выкинуть каталоги *-merged/*.menu, то всё просто: комбинаторное
сочетание кусков, зависимых/независимых от DE и дистрибутивов, затем
навороты. Эти каталоги можно включить в остальную картину позже в виде
отдельного <MergeDir> в подходящих для этого файлах (скорее всего, в
applications-base.menu и <de>-applications-base.menu соответственно).

Из [1] я вынес тезис: брендинг должен быть в состоянии переписать всё
меню с нуля, что согласно [2] фактически означает, что брендинг должен
применяться последним. Но брендинг должен быть в состоянии использовать
"штатное" меню. Из этого следует, что:
applications-<distro>.menu может мержить в себя applications-base.menu
(но не обязан). applications-base.menu не может мержить в себя
applications-<distro>.menu, потому что тогда становится очень неудобно
переписывать меню (см. [1]).
Аналогично, для <de>-applications-<distro>.menu и
<de>-applications-bases.menu.
Соответственно, точкой входа для построения меню могут быть либо
applications-<distro>.menu, либо <de>-applications-<distro>.menu. Из
этих двоих второй будет непустым с большей вероятностью (ибо у нас
сейчас сильно разнятся структуры меню для разных сред), поэтому имеет
смысл, чтобы <de>-applications-<distro>.menu мержил в себя
applications-<distro>.menu, а не наоборот.
Какой бы ни была точка входа, последним пунктом в ней должен быть мерж
*applications-admin.menu, причём в дистрибутиве этих файлов,
естественно, нет (или есть, но пустые).

Итого получаем такую картинку:
applications-<distro>.menu
  включает в себя (опционально) applications-base.menu
  формирует необходимую для дистрибутива структуру меню
  включает в себя applications-admin.menu

<de>-applications-<distro>.menu
  включает в себя (опционально) <de>-applications-base.menu
  включает в себя applications-<distro>.menu
  формирует необходимую для DE в дистрибутиве структуру меню
  включает в себя <de>-applications-admin.menu

Теперь о том, где что должно лежать (я уже почти закончил, держитесь).
Согласно [2], точкой входа должен быть либо
файл /etc/xdg/menus/applications.menu,
либо /etc/xdg/menus/<de>-applications.menu, где <de> берётся из
переменной XDG_MENU_PREFIX (для GNOME соответствующий баг [4] уже
закрыт). Соответственно, то что мы называли applications-<distro>.menu и
<de>-applications-<distro>.menu, в реальной жизни потеряет суффикс
-<distro>. Это приведёт к конфликтам (пакетным либо файловым) между
branding-пакетами, строящими меню для конкретных дистрибутивов. Можно
развязать этот конфликт через альтернативы, если нужно (не уверен, что
нужно). Названия остальных файлов можно выбирать почти произвольно, при
условии чтобы их можно было мержить друг в друга так, как я описал выше.
Соответственно, раскладка по пакетам предлагается такая:
branding-<distro>-menus - содержит applications.menu (ну или даже связку
из <de>-applications.menu, если их несколько на дистрибутив)
branding-<distro>-<de>-menus либо branding-<distro>-<de>-settings, как
сейчас - содержит <de>-applications.menu для конкретного дистрибутива.
gnome-menus, kde4libs и т.д. - содержат <de>-applications-base.menu и
подходящий каталог для <de>-applications-merged/*.menu (когда-то такое
уже было, кажется...)
altlinux-menus - содержит applications-base.menu и
каталог /etc/xdg/menus/applications-merged/

Дочитали? Молодцы. Теперь, если остались силы высказаться, выскажитесь,
пожалуйста. Спасибо за внимание, ваш звонок очень важен для нас.

[1] https://bugzilla.altlinux.org/20797
[2] http://standards.freedesktop.org/menu-spec/latest/
[3] https://bugzilla.altlinux.org/20829
[4] https://bugzilla.altlinux.org/20852

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team
----------- ��������� ����� -----------
���� ������� �������� �� � ��������� �������...
���     : �����������
���     : application/pgp-signature
������  : 197 ������
��������: ??? ????? ????????? ????????? ???????? ????????
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20090724/26fada7a/attachment-0001.bin>


More information about the Devel mailing list