[devel] RFC: XDG menus

[devel] RFC: XDG menus

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 11354 bytes --]

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

У меня сейчас будет большое письмо, зато про тему, в которой все
(считают что) разбираются :) - я сейчас поговорю про меню в
дистрибутивах, создаваемых на базе технологий 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

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] RFC: XDG menus

[Michael Shigorin]

On Fri, Jul 24, 2009 at 01:04:13AM +0400, Alexey Rusakov wrote:
> Я предполагаю, что читающие уже ознакомились хотя бы по
> диагонали с fd.o-шным документом [2]

Разве что по диагонали...

> Это приведёт к конфликтам (пакетным либо файловым) между
> branding-пакетами, строящими меню для конкретных дистрибутивов.
> Можно развязать этот конфликт через альтернативы, если нужно
> (не уверен, что нужно).

Зачем на одном корне несколько branding-* с аналогичным смыслом?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] RFC: XDG menus

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

В Сбт, 25/07/2009 в 10:49 +0300, Michael Shigorin пишет:
> On Fri, Jul 24, 2009 at 01:04:13AM +0400, Alexey Rusakov wrote:
> > Я предполагаю, что читающие уже ознакомились хотя бы по
> > диагонали с fd.o-шным документом [2]
> 
> Разве что по диагонали...
Для понимания смысла письма подробнее и не нужно.

> > Это приведёт к конфликтам (пакетным либо файловым) между
> > branding-пакетами, строящими меню для конкретных дистрибутивов.
> > Можно развязать этот конфликт через альтернативы, если нужно
> > (не уверен, что нужно).
> 
> Зачем на одном корне несколько branding-* с аналогичным смыслом?
Не знаю. Потому и не уверен, что нужно.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] RFC: XDG menus

[Michael Shigorin]

On Sat, Jul 25, 2009 at 01:02:01PM +0400, Alexey Rusakov wrote:
> > > Это приведёт к конфликтам (пакетным либо файловым) между
> > > branding-пакетами, строящими меню для конкретных дистрибутивов.
> > Зачем на одном корне несколько branding-* с аналогичным смыслом?
> Не знаю. Потому и не уверен, что нужно.

Должно быть даже невозможно, я бы сказал.

До кучи, branding-altlinux-*-release содержат /etc/altlinux-release. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] RFC: XDG menus

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 4408 bytes --]

В Пнд, 27/07/2009 в 13:30 +0000, Sergey V Turchin пишет:
> On Thursday 23 July 2009, Alexey Rusakov wrote:
> 
> [...]
> > applications-user.menu. Пользовательские навороты. Этой части я
> > далее не касаюсь: она лежит у пользователя в домашнем каталоге и
> > пользователь может для себя сделать любой закат солнца, какой
> > хочет.
> Я специально переименовал везде слово applications-kmenuedit.menu в 
> applications-menueditor.menu для этого.
> Могу еще раз переименовать.
Я немного другое имел в виду, а именно, содержимое ~/.config/menus. Если
в KDE есть возможность править системную структуру меню, то
-menueditor.menu скорее соответствует тому, что я назвал
applications-admin.menu. Переименовывать без нужды незачем, конечно.

> [...]
> > Дочитали? Молодцы. Теперь, если остались силы высказаться,
> > выскажитесь, пожалуйста. Спасибо за внимание, ваш звонок очень
> > важен для нас.
> 1. Можно переместить описание структуры меню в 
> /etc/xdg/menus/applications-merged/applications.menu
Возможно, это имеет смысл. Но при этом мы приходим к тому, что если в
каком-нибудь branding-что-нибудь-* захочется переписать структуру меню
полностью, придётся отказаться от мержа из этого каталога вообще.
Наверное, это по-своему тоже правильно.

> 2. Оставить /etc/xdg/menus/applications.menu в текущем состоянии.
Вообще текущее (после недавнего обновления) состояние этого файла меня
скорее радует. Разве что за исключением того, что Settingsmenu в GNOME
называется Settings и в умолчальной конфигурации показывается вообще вне
иерархии, в рамках отдельного меню (под названием "Система"). Можно
сделать так, чтобы показывалось внутри одного общего меню, но оно при
этом всё равно будет Settings.

> 3. Использовать файлы /etc/xdg/menus/<DE>-applications.menu с 
> содержимым как у /etc/xdg/menus/applications.menu плюс специфичные 
> для среды вещи типа 
> <Include><And><Category>KDE</Category><Category>Core</Category></And></Include>
Если в файлах .desktop корректно прописаны OnlyShowIn, то это, по идее,
не должно понадобиться.

Предлагаю сделать так: оставить applications.menu в его нынешнем
состоянии; в <DE>-applications.menu прописываем DE-специфичные вещи,
если надо; в branding-* перекрывать эти два файла по мере необходимости
с подменой соответствующих пакетов (altlinux-menus, gnome-menus, ...). А
дальше посмотрим.

altlinux-menus можно более-менее нормально заменять (при необходимости)
другим пакетом с Provides: altlinux-menus, за исключением того, что апту
сносит крышу, когда пакет предоставляет зависимость (без Obsoletes) с
тем же именем, что и некоторый реальный пакет. gnome-menus я (пока у
себя на машине) переработал так, чтобы его тоже можно было легко
перекрыть, вроде работает.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] RFC: XDG menus

[Sergey V Turchin]

[-- Attachment #1: Type: Text/Plain, Size: 1071 bytes --]

On Thursday 23 July 2009, Alexey Rusakov wrote:

[...]
> applications-user.menu. Пользовательские навороты. Этой части я
> далее не касаюсь: она лежит у пользователя в домашнем каталоге и
> пользователь может для себя сделать любой закат солнца, какой
> хочет.
Я специально переименовал везде слово applications-kmenuedit.menu в 
applications-menueditor.menu для этого.
Могу еще раз переименовать.

[...]
> Дочитали? Молодцы. Теперь, если остались силы высказаться,
> выскажитесь, пожалуйста. Спасибо за внимание, ваш звонок очень
> важен для нас.
1. Можно переместить описание структуры меню в 
/etc/xdg/menus/applications-merged/applications.menu
2. Оставить /etc/xdg/menus/applications.menu в текущем состоянии.
3. Использовать файлы /etc/xdg/menus/<DE>-applications.menu с 
содержимым как у /etc/xdg/menus/applications.menu плюс специфичные 
для среды вещи типа 
<Include><And><Category>KDE</Category><Category>Core</Category></And></Include>

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] RFC: XDG menus

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 5853 bytes --]

В Пнд, 27/07/2009 в 16:56 +0000, Sergey V Turchin пишет:
> On Monday 27 July 2009, Alexey Rusakov wrote:
> > В Пнд, 27/07/2009 в 13:30 +0000, Sergey V Turchin пишет:
> > > On Thursday 23 July 2009, Alexey Rusakov wrote:
> > > Я специально переименовал везде слово
> > > applications-kmenuedit.menu в applications-menueditor.menu для
> > > этого.
> > > Могу еще раз переименовать.
> >
> > Я немного другое имел в виду, а именно, содержимое
> > ~/.config/menus.
> Я тоже. Прописано в /etc/xdg/applications.menu , а использовать 
> ~/.config/menus/applications-menueditor.menu
А, ну да :) Меня заклинило на обратном варианте, который сейчас в
редакторе меню GNOME: в ~/.config/menus/applications.menu мержится
глобальный applications.menu. Почти без разницы, лишь бы не циклило.

> > Если в KDE есть возможность править системную
> > структуру меню, то -menueditor.menu скорее соответствует тому,
> > что я назвал applications-admin.menu. Переименовывать без нужды
> > незачем, конечно.
> Для этого можно использовать /etc/xdg/applications-
> merged/файлы_с_любым_именем.menu
Они мержатся в неопределённом порядке. Include/Exclude'ы перепутаться
могут.

> > Возможно, это имеет смысл. Но при этом мы приходим к тому, что
> > если в каком-нибудь branding-что-нибудь-* захочется переписать
> > структуру меню полностью, придётся отказаться от мержа из этого
> > каталога вообще. Наверное, это по-своему тоже правильно.
> Нет, наоборот, использовать этот каталог будет без проблем, т.к. 
> структура меню будет одна.
А если я как раз её-то хочу переписать? Совсем, с нуля? Я же говорю, вся
эта моя песня про меню сейчас началась с того, что понадобилось сделать
очень простое меню без структуры вообще.

> > > 2. Оставить /etc/xdg/menus/applications.menu в текущем
> > > состоянии.
> > Вообще текущее (после недавнего обновления) состояние этого файла
> > меня скорее радует. Разве что за исключением того, что
> > Settingsmenu в GNOME называется Settings и в умолчальной
> > конфигурации показывается вообще вне иерархии, в рамках
> > отдельного меню (под названием "Система"). Можно сделать так,
> > чтобы показывалось внутри одного общего меню, но оно при этом всё
> > равно будет Settings.
> Все, что не получиться уместить в общий файл 
> /etc/xdg/menus/applications-merged/applications.menu , можно будет 
> сделать в /etc/xdg/menus/<DE>-applications.menu
Это да.

> > Предлагаю сделать так: оставить applications.menu в его нынешнем
> > состоянии; в <DE>-applications.menu прописываем DE-специфичные
> > вещи, если надо; в branding-* перекрывать эти два файла по мере
> > необходимости с подменой соответствующих пакетов (altlinux-menus,
> > gnome-menus, ...). А дальше посмотрим.
> Не нужно будет ничего подменять. Подмену пакетов я вообще не 
> одобряю. alternatives пока что единственный нормальный способ 
> подмены. Можно просто класть файлы в /etc/xdg/menus/applications-
> merged/ и ничего не подменять
Файлы из applications-merged/ мержатся в неопределённом спецификацией
порядке. Если в системе будет стоять два пакета, кладущих каждый свою
структуру меню, на выходе получим "много-много хороших меню" (с) /me в
#20829. Имхо, лучше даже файловые конфликты у пакетов, чем такое вот.
И снова: если понадобится не подредактировать, а полностью переписать
меню, вариант с applications-merged/ приводит к извратам типа
описанного в https://bugzilla.altlinux.org/show_bug.cgi?id=20797

> Я вообще против подмены пакетов. С текущим rpm и без alternatives 
> это кроме как на изврат больше ни на что не тянет. Например, в SuSE 
> видел что-то типа
> Conflicts: all_provides(имяпакета)
Ой, мама. Ну в общем да, у нас с branding-* та же фигня уже во весь рост
нарисовалась.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] RFC: XDG menus

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 4769 bytes --]

В Пнд, 27/07/2009 в 20:00 +0000, Sergey V Turchin пишет:
> On Monday 27 July 2009, Alexey Rusakov wrote:
> 
> [...]
> > сейчас в
> > редакторе меню GNOME: в ~/.config/menus/applications.menu
> > мержится глобальный applications.menu. Почти без разницы, лишь бы
> > не циклило.
> Можно пропатчить gnome-menus, чтоб использовал 
> ~/.config/menus/applications-menueditor.menu
> Это просто и цикла точно не будет.
Это не gnome-menus, это alacarte нужно патчить. Не суть. Да, можно.
Кстати, будет дополнительное облегчение жизни мигрантам с KDE на GNOME,
менюшки в основном восстановятся.

> > > > Если в KDE есть возможность править системную
> > > > структуру меню, то -menueditor.menu скорее соответствует
> > > > тому, что я назвал applications-admin.menu. Переименовывать
> > > > без нужды незачем, конечно.
> > >
> > > Для этого можно использовать /etc/xdg/applications-
> > > merged/файлы_с_любым_именем.menu
> > Они мержатся в неопределённом порядке. Include/Exclude'ы
> > перепутаться могут.
> А нужно ли нам более 1-го файла?
> 
> > А если я как раз её-то хочу переписать? Совсем, с нуля?
> > Я же
> > говорю, вся эта моя песня про меню сейчас началась с того, что
> > понадобилось сделать очень простое меню без структуры вообще.
> В начале описания могут быть еще одно или несколько правил, 
> отправляющие текущее меню в нуль.
М-м, поясни, каким образом?
<Menu><Name>Applications</Name><Deleted/></Menu> у меня в GNOME не
сработало. Я уже давно ищу такую штуку, если ты про неё знаешь, тогда и
разговора нет.

> [...]
> > Файлы из applications-merged/ мержатся в неопределённом
> > спецификацией порядке. Если в системе будет стоять два пакета,
> > кладущих каждый свою структуру меню,
> > на выходе получим
> > "много-много хороших меню" (с) /me в #20829.
> Думаю, лучше иметь только 1 такой файл/пакет для каждого конкретного 
> дистрибутива. Тогда вероятность того, что нечаянно поставят еще 
> один, будет мала, несмотря на то, что они не будут конфликтовать 
> никак. Порядок не будет иметь значения, т.к. 1 файл.
Ты загляни в Сизиф и посмотри, сколько уже разных branding-* пакетов там
есть. Кто бы спорил что лучше. Мой вариант, когда у пакетов будут
файловые конфликты, вообще не даёт поставить в систему больше одного
такого пакета. Правда, довольно грубым способом.

> > Имхо, лучше даже
> > файловые конфликты у пакетов, чем такое вот. И снова: если
> > понадобится не подредактировать, а полностью переписать меню,
> > вариант с applications-merged/ приводит к извратам типа
> > описанного в https://bugzilla.altlinux.org/show_bug.cgi?id=20797
> У меня вроде бы это и получалось без извратов в пакетах kde-
> settings-junior*
Тебе в них не нужно было полностью переписывать меню. Повторюсь, то из
чего вырос упомянутый баг - необходимость сделать очень простое меню без
структуры вообще. То есть тыкаешь в "Приложения" - а там список из 7 или
8 приложений, вот и всё меню.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] RFC: XDG menus

[Sergey V Turchin]

[-- Attachment #1: Type: Text/Plain, Size: 3967 bytes --]

On Monday 27 July 2009, Alexey Rusakov wrote:
> В Пнд, 27/07/2009 в 13:30 +0000, Sergey V Turchin пишет:
> > On Thursday 23 July 2009, Alexey Rusakov wrote:
> >
> > [...]
> >
> > > applications-user.menu. Пользовательские навороты. Этой части
> > > я далее не касаюсь: она лежит у пользователя в домашнем
> > > каталоге и пользователь может для себя сделать любой закат
> > > солнца, какой хочет.
> >
> > Я специально переименовал везде слово
> > applications-kmenuedit.menu в applications-menueditor.menu для
> > этого.
> > Могу еще раз переименовать.
>
> Я немного другое имел в виду, а именно, содержимое
> ~/.config/menus.
Я тоже. Прописано в /etc/xdg/applications.menu , а использовать 
~/.config/menus/applications-menueditor.menu

> Если в KDE есть возможность править системную
> структуру меню, то -menueditor.menu скорее соответствует тому,
> что я назвал applications-admin.menu. Переименовывать без нужды
> незачем, конечно.
Для этого можно использовать /etc/xdg/applications-
merged/файлы_с_любым_именем.menu

> > [...]
> >
> > > Дочитали? Молодцы. Теперь, если остались силы высказаться,
> > > выскажитесь, пожалуйста. Спасибо за внимание, ваш звонок
> > > очень важен для нас.
> >
> > 1. Можно переместить описание структуры меню в
> > /etc/xdg/menus/applications-merged/applications.menu
>
> Возможно, это имеет смысл. Но при этом мы приходим к тому, что
> если в каком-нибудь branding-что-нибудь-* захочется переписать
> структуру меню полностью, придётся отказаться от мержа из этого
> каталога вообще. Наверное, это по-своему тоже правильно.
Нет, наоборот, использовать этот каталог будет без проблем, т.к. 
структура меню будет одна.

> > 2. Оставить /etc/xdg/menus/applications.menu в текущем
> > состоянии.
> Вообще текущее (после недавнего обновления) состояние этого файла
> меня скорее радует. Разве что за исключением того, что
> Settingsmenu в GNOME называется Settings и в умолчальной
> конфигурации показывается вообще вне иерархии, в рамках
> отдельного меню (под названием "Система"). Можно сделать так,
> чтобы показывалось внутри одного общего меню, но оно при этом всё
> равно будет Settings.
Все, что не получиться уместить в общий файл 
/etc/xdg/menus/applications-merged/applications.menu , можно будет 
сделать в /etc/xdg/menus/<DE>-applications.menu

> > 3. Использовать файлы /etc/xdg/menus/<DE>-applications.menu с
> > содержимым как у /etc/xdg/menus/applications.menu плюс
> > специфичные для среды вещи типа
> > <Include><And><Category>KDE</Category><Category>Core</Category>
> ></And></Include>
>
> Если в файлах .desktop корректно прописаны OnlyShowIn, то это, по
> идее, не должно понадобиться.
Это просто пример. Может быть еще что-то. Главная задача -- не 
патчить кучу .desktop-файлов

> Предлагаю сделать так: оставить applications.menu в его нынешнем
> состоянии; в <DE>-applications.menu прописываем DE-специфичные
> вещи, если надо; в branding-* перекрывать эти два файла по мере
> необходимости с подменой соответствующих пакетов (altlinux-menus,
> gnome-menus, ...). А дальше посмотрим.
Не нужно будет ничего подменять. Подмену пакетов я вообще не 
одобряю. alternatoves пока что единственный нормальный способ 
подмены. Можно просто класть файлы в /etc/xdg/menus/applications-
merged/ и ничего не подменять

> altlinux-menus можно более-менее нормально заменять (при
> необходимости) другим пакетом с Provides: altlinux-menus, за
> исключением того, что апту сносит крышу, когда пакет
> предоставляет зависимость (без Obsoletes) с тем же именем, что и
> некоторый реальный пакет. gnome-menus я (пока у себя на машине)
> переработал так, чтобы его тоже можно было легко перекрыть, вроде
> работает.
Я вообще против подмены пакетов. С текущим rpm и без alternatives 
это кроме как на изврат больше ни на что не тянет. Например, в SuSE 
видел что-то типа
Conflicts: all_provides(имяпакета)

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] RFC: XDG menus

[Sergey V Turchin]

[-- Attachment #1: Type: Text/Plain, Size: 2020 bytes --]

On Monday 27 July 2009, Alexey Rusakov wrote:

[...]
> сейчас в
> редакторе меню GNOME: в ~/.config/menus/applications.menu
> мержится глобальный applications.menu. Почти без разницы, лишь бы
> не циклило.
Можно пропатчить gnome-menus, чтоб использовал 
~/.config/menus/applications-menueditor.menu
Это просто и цикла точно не будет.

> > > Если в KDE есть возможность править системную
> > > структуру меню, то -menueditor.menu скорее соответствует
> > > тому, что я назвал applications-admin.menu. Переименовывать
> > > без нужды незачем, конечно.
> >
> > Для этого можно использовать /etc/xdg/applications-
> > merged/файлы_с_любым_именем.menu
> Они мержатся в неопределённом порядке. Include/Exclude'ы
> перепутаться могут.
А нужно ли нам более 1-го файла?

> А если я как раз её-то хочу переписать? Совсем, с нуля?
> Я же
> говорю, вся эта моя песня про меню сейчас началась с того, что
> понадобилось сделать очень простое меню без структуры вообще.
В начале описания могут быть еще одно или несколько правил, 
отправляющие текущее меню в нуль.

[...]
> Файлы из applications-merged/ мержатся в неопределённом
> спецификацией порядке. Если в системе будет стоять два пакета,
> кладущих каждый свою структуру меню,
> на выходе получим
> "много-много хороших меню" (с) /me в #20829.
Думаю, лучше иметь только 1 такой файл/пакет для каждого конкретного 
дистрибутива. Тогда вероятность того, что нечаянно поставят еще 
один, будет мала, несмотря на то, что они не будут конфликтовать 
никак. Порядок не будет иметь значения, т.к. 1 файл.

> Имхо, лучше даже
> файловые конфликты у пакетов, чем такое вот. И снова: если
> понадобится не подредактировать, а полностью переписать меню,
> вариант с applications-merged/ приводит к извратам типа
> описанного в https://bugzilla.altlinux.org/show_bug.cgi?id=20797
У меня вроде бы это и получалось без извратов в пакетах kde-
settings-junior*

[...]

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]