Created attachment 3677 [details] /etc/gnome/xdg/menus не нужен, используем стандартное место Когда-то давным-давно был ALT Bug 9592, патч из которого до сих пор успешно прилагается. Однако вдумчивое чтение спецификации fd.o, в частности, раздела File locations: http://standards.freedesktop.org/menu-spec/latest/ar01s02.html, навело меня на мысль, что положив файл applications.menu в правильное место и назвав его правильным образом, можно избавиться от странного места /etc/gnome/xdg/menus, в котором всё равно больше ничего кроме этого файла не лежит. Предположение оказалось верным: следующая команда mv /etc/gnome/xdg/menus/applications-merged/applications.menu /etc/xdg/menus/applications-merged/gnome-applications.menu оставляет результирующую структуру меню такой же, но при этом избавляет нас от необходимости хардкодить в libgnome-menus путь /etc/gnome/xdg/menus и вообще использовать этот путь. Итого, предлагается: 1. Применить к gnome-menus.spec прилагаемый патч. 2. Выбросить gnome-menus-2.14-add-config-dir.patch за ненадобностью.
Представь, если я сделаю то же самое для 2-х KDE
Будет много-много хороших меню :) Понятно, в общем, нужен ещё один патч, который приведёт gnome-menus в соответствие с menu-spec и позволит зачитывать конфигурацию меню из средо-специфичных файлов (gnome-applications.menu, kde-applications.menu и т.п.), в зависимости от состояния переменной XDG_MENU_PREFIX. На данный момент то ли механизма совсем нет, то ли он не работает, потому что переменная не выставляется.
Проверил. В GNOME механизм замечательно работает, достаточно выставить упомянутую переменную :) Пойду писать фичереквест на gnome-session.
gnome-session-2.26.2-alt2 -> sisyphus: * Thu Jul 23 2009 Yuri N. Sedunov <aris@altlinux> 2.26.2-alt2 - set XDG_MENU_PREFIX variable to "gnome-" in startgnome2 (closes #20829)
Таки 20852 закрыт этой сборкой, а не 20829 :)
Проблема будет во всех меню, отличных от того, которое захотим кастомизировать, т.к. applications-merged/my-custom.menu будет зависеть на конкретную структуру меню, но подгребаясь всеми остальными приводить к нежелательным результатам. XDG_MENU_PREFIX здесь не поможет, зато давно работает текущий вариант, когда applications-merged/my-custom.menu находиться в недоступном для остальных месте.
Мысль понятна. Но давайте тогда хотя бы не хардкодить такие вещи. Давайте, например, добавлять в XDG_CONFIG_DIRS пути типа /etc/gnome или /etc/kde. Даже это будет поприличнее.
Выльестся в тот же самуй же хардкод. KDE-шная программа может быть запущена не из-под GNOME, но меню GNOME-specific ей вряд ли будет нужен. Кто ей выставит нужный XDG_CONFIG_DIRS? Тот самый хардкод.
XDG_CONFIG_DIRS можно выставить при входе в сессию, точно так же как по результатам Bug 20852 в GNOME будет выставляться XDG_MENU_PREFIX. Но для начала я бы всё-таки задался вопросом, нужно ли придумывать отдельные applications-merged для разных сред. Просто ты для Юниора когда-то придумывал иерархию только под KDE, и в Юниоре только KDE и был, остальные среды на птичьих правах. Сейчас boyarsh@ проводит кастомизацию дистрибутива для конкретного заказчика, в этом дистрибутиве будет только GNOME. Если всё-таки нужно, давайте выставлять XDG_CONFIG_DIRS - всё же это дополнительная ручка для варьирования путей, в отличие от прибивания гвоздями какого-то определённого пути в код, мимо которого потом ни проехать, ни пройти.
(В ответ на комментарий №9) > я бы всё-таки задался вопросом, нужно ли придумывать отдельные > applications-merged для разных сред. Когда в applications.menu переместиться структура меню, которая сейчас раздельно, тогда будет не нужно. > Просто ты для Юниора когда-то придумывал > иерархию только под KDE, и в Юниоре только KDE и был, остальные среды на > птичьих правах. Сейчас boyarsh@ проводит кастомизацию дистрибутива для > конкретного заказчика, в этом дистрибутиве будет только GNOME. Я делал так, что б не гадить остальным. > Если всё-таки нужно, давайте выставлять XDG_CONFIG_DIRS Я уже объяснил, почему это будет тот же самый патч, только выставляющий XDG_CONFIG_DIRS, а не просто добавляющий каталог. Т.е. шило на мыло, но реализация сложнее.
Это не хардкод. Отредактировать /usr/bin/start* можно обычным текстовым редактором (из-под рута, конечно) - это, конечно, не конфигфайл, но всё-таки. Дальше, тот же XDG_CONFIG_DIRS можно изменить из какого-нибудь ~/.xinitrc, тем самым, например, в XFCE сделать структуру меню от GNOME, и наоборот, в GNOME от "родной" структуры отказаться. Ничего этого сейчас сделать нельзя, иначе чем удалив файлы из /etc/*/xdg/menus.
(В ответ на комментарий №11) > Это не хардкод. Этот "не хардкод" не будет работать для программы из комплекта GNOME, запущенной из любой другой среды.
Плохо ли это? Если в каком-нибудь гномьем редакторе меню, запущенном в другой среде, будет показываться то меню, которое актуально для этой среды, а не для GNOME - разве это плохо?
Редактор меню -- единственная программа, в которой текущее меню имеет смысл, но она сама не имеет смысла, если есть более родной редактор меню. Хотя, в этом случае, все-таки не должно быть никаких проблем. Проблема, пожалуй, только в файле кастомизации, если он частично покорежит то меню, которое не учитывает.
Выключил /etc/gnome/xdg/menus, переместил структуру меню в gnome-applications.menu. Когда понадобится кастомизировать именно гномье меню, что-нибудь изменю (например, добавлю каталог /etc/xdg/menus/gnome-applications-merged/). Но я не слишком верю в то, что такие прецеденты будут.
FIXED
(В ответ на комментарий №15) > /etc/xdg/menus/gnome-applications-merged/ Но, это, ведь, то же, что и /etc/gnome/xdg/menus/applications-merged/ , только сбоку ...
(В ответ на комментарий №17) > (В ответ на комментарий №15) > > /etc/xdg/menus/gnome-applications-merged/ > Но, это, ведь, то же, что и /etc/gnome/xdg/menus/applications-merged/ , только > сбоку ... В принципе да, но оно, по крайней мере, лежит внутри XDG_CONFIG_DIR. Ну и опять-таки - пусть оно сначала понадобится.
Тогда я в KDE ничего менять не буду до того времени, когда понадобиться. Друг другу не мешаем.
Да, конечно.
